En Cloudflare, nos sentimos orgullosos de ofrecer a todos los clientes la posibilidad de que sus aplicaciones de Internet cuenten con un certificado TLS de forma gratuita. En la actualidad, somos responsables de gestionar el ciclo de vida de casi 45 millones de certificados, desde su emisión hasta su implementación y renovación. Conforme desarrollamos la plataforma más flexible y sólida del mundo, queremos que además tenga garantía ante el futuro y que se adapte a los casos que no podemos predecir.
Los casos que nos obligan a volver a emitir certificados para nuestros clientes, tales como claves en riesgo, vulnerabilidades y revocaciones masivas, requieren una acción inmediata. De lo contrario, la seguridad de los clientes puede verse amenazada o su servicio puede sufrir interrupciones. Cuando se produce uno de estos casos, queremos estar preparados para mitigar el impacto inmediatamente. ¿Pero cómo?
Con un certificado de copia de seguridad que está listo para su implementación con una clave privada diferente y emitido por una autoridad de certificación distinta a la del certificado original que entregamos.
Casos en los que hay que volver a emitir certificados
Cloudflare emite nuevos certificados todos los días, lo que llamamos renovación de certificados. Como los certificados tienen fecha de caducidad, cuando vemos que uno va a caducar pronto, iniciamos una nueva petición de renovación del certificado. De esta manera, para cuando el certificado expire, ya tendremos un certificado actualizado, implementado y listo para usar para la terminación TLS.
Lamentablemente, no todas las renovaciones de certificados se inician antes de la fecha de caducidad. A veces, acontecimientos imprevisibles como el hecho de que las claves estén en riesgo pueden propiciar la renovación de certificados. La razón es que es necesario emitir una nueva clave y, por tanto, también el certificado correspondiente.
Claves en riesgo
Una clave está en riesgo cuando una persona o sistema no autorizado obtiene la clave privada que se utiliza para cifrar y descifrar información secreta, la peor pesadilla de los equipos de seguridad. El hecho de que la clave esté en riesgo puede ser el resultado de una vulnerabilidad, como Heartbleed, donde un error en un sistema puede causar la fuga de la clave privada. También pueden ser el resultado de acciones malintencionadas, como el acceso de un empleado deshonesto a información no autorizada. En caso de que la clave se vea comprometida, es de vital importancia que (1) se emitan inmediatamente nuevas claves privadas, (2) se implementen nuevos certificados y (3) se revoquen los antiguos.
Vulnerabilidad Heartbleed
En 2014, se hizo pública la vulnerabilidad Heartbleed. Permitía a los atacantes extraer la clave privada del certificado TLS de cualquier servidor que ejecutara la versión afectada de OpenSSL, una popular biblioteca de cifrado. Parcheamos el fallo y, como medida de precaución, volvimos a emitir rápidamente las claves privadas y los certificados TLS de todos nuestros clientes, aunque no se filtró ninguna de nuestras claves. Nuestra rápida capacidad de respuesta evitó que los datos de nuestros clientes quedaran expuestos.
Heartbleed fue una llamada de atención. En aquel momento, la escala de Cloudflare era de magnitud inferior. Con una vulnerabilidad similar a la escala actual tardaríamos semanas, no horas, en volver a emitir los certificados de todos nuestros clientes.
Ahora, con los certificados de copia de seguridad, no tenemos que preocuparnos de iniciar una emisión masiva de certificados nuevos en un plazo de tiempo reducido. En su lugar, los clientes ya tendrán un certificado que podremos implementar al instante. Y no solo eso, sino que el certificado de copia de seguridad también cuenta con una clave diferente a la del certificado original, lo que evitará que se vea afectado por la clave en riesgo.
Las claves en riesgo son una de las principales razones por las que es necesario volver a emitir certificados a escala. Sin embargo, también hay otros casos que pueden provocar la emisión nueva de certificados, como las revocaciones masivas por parte de autoridades de certificación.
Revocaciones masivas de las autoridades de certificación
En la actualidad, el Foro de Autoridades de Certificación y Navegadores (CA/B) es el organismo que establece las reglas y normas para los certificados. Uno de los requisitos básicos establecidos por el Foro CA/B indica que las autoridades de certificación están obligadas a revocar los certificados cuyas claves están en riesgo en un plazo de 24 horas. En el caso de problemas menos urgentes, como el uso indebido de certificados o la violación de la política de certificados de una autoridad de certificación, los certificados se deben revocar en un plazo de cinco días. En ambos casos, los certificados serán revocados por la autoridad de certificación en un plazo breve y se requiere la reedición inmediata de los certificados.
Si bien las autoridades de certificación no suelen iniciar las revocaciones masivas, en los últimos años se han dado algunos casos. Recientemente, Let's Encrypt tuvo que revocar aproximadamente 2,7 millones de certificados cuando descubrió un caso de incumplimiento en la implementación de un desafío de Validación de control de dominio (DCV). En este caso, los clientes de Cloudflare no se vieron afectados.
En otra ocasión, una de las autoridades de certificación que utilizamos descubrió que estaban renovando certificados basados en tokens de validación que no cumplían con los estándares del Foro CA/B. Por este motivo, tuvieron que recurrir a una revocación masiva que afectó a 5000 dominios administrados por Cloudflare. Trabajamos con nuestros clientes y con la autoridad de certificación para emitir nuevos certificados antes de la revocación, de ahí que el impacto fuera mínimo.
Entendemos que hay errores, y hemos tenido la suerte de que cuando han surgido estos problemas, nuestros equipos de ingeniería han podido mitigarlos rápidamente para que ningún cliente se viera afectado. Sin embargo, no es suficiente. Nuestros sistemas deben estar preparados para el futuro, de modo que una revocación de 45 millones de certificados no tenga ningún impacto en nuestros clientes. Con los certificados de copia de seguridad, estaremos preparados para una reedición masiva, sin importar la escala.
Para poder responder a las revocaciones masivas iniciadas por nuestras autoridades de certificación, vamos a emitir cada certificado de copia de seguridad desde una autoridad diferente a la del certificado original. De este modo, añadiremos una capa de protección en caso de que una de nuestras autoridades de certificación tenga que recurrir a una revocación masiva, algo que, cuando ocurre, es una bomba de relojería.
Desafíos a la hora de renovar certificados
Escala: un gran poder conlleva una gran responsabilidad
Cuando se expuso la vulnerabilidad Heartbleed, tuvimos que volver a emitir unos 100 000 certificados. En ese momento, no nos supuso un desafío. Ahora, somos responsables de decenas de millones de certificados. Si bien nuestros sistemas son capaces de manejar esta escala, confiamos en que nuestras autoridades de certificación socias también puedan hacerlo. En caso de emergencia, no queremos confiar en sistemas que no controlamos. Por eso es importante que emitamos certificados con antelación, para que durante un desastre solo tengamos que preocuparnos de implementar certificados de copia de seguridad.
Intervención manual para completar la DCV
Otro reto que conlleva la emisión nueva de certificados es la Validación de control de dominio. La DCV es una comprobación utilizada para validar la propiedad de un dominio antes de que una autoridad de certificación pueda emitir su certificado. Cuando los clientes se incorporan a Cloudflare, pueden autorizarnos a ser su proveedor de DNS, o pueden optar por utilizar Cloudflare como proxy manteniendo su actual proveedor de DNS.
Cuando Cloudflare actúa como proveedor de DNS para un dominio, podemos añadir registros de DCV en nombre de nuestro cliente. De este modo, el proceso de emisión y renovación de certificados es mucho más sencillo.
Los dominios que no utilizan Cloudflare como su proveedor de DNS, a los que llamamos zonas parciales, tienen que confiar en otros métodos para completar la DCV. Cuando esos dominios nos delegan el tráfico, podemos completar la DCV HTTP en su nombre, sirviendo el token de DCV HTTP desde nuestro perímetro. Sin embargo, los clientes que quieren que su certificado se emita antes de redireccionar su tráfico mediante proxy tienen que completar manualmente la DCV. En caso de que Cloudflare tenga que reeditar miles o millones de certificados, pero no pueda completar la DCV en nombre del cliente, será necesaria la intervención manual. Si bien completar la DCV no es una tarea ardua, no es algo que debamos confiar a nuestros clientes en caso de emergencia, cuando tienen un margen de tiempo escaso y un alto riesgo asociado.
Aquí es donde entran en juego los certificados de copia de seguridad. A partir de ahora, cada emisión de certificados lanzará dos peticiones: una para un certificado de la autoridad de certificación primaria y otra para el certificado de copia de seguridad. Cuando podamos completar la DCV en nombre del cliente, lo haremos para ambas autoridades de certificación.
A día de hoy, solo emitimos certificados de copia de seguridad para los dominios que utilizan Cloudflare como proveedor de DNS autoritativo. En el futuro, solicitaremos certificados de copia de seguridad para zonas parciales. Esto significa que para los certificados de copia de seguridad para los que no podemos completar la DCV, daremos a los clientes los registros DCV correspondientes para que se emita el certificado.
Plan de implementación de certificados de copia de seguridad
Nos complace anunciar que Cloudflare ha comenzado a implementar certificados de copia de seguridad en las peticiones de certificados universales para los clientes gratuitos que utilizan Cloudflare como proveedor de DNS autoritativo. Hemos ido aumentando progresivamente el número de peticiones de certificados de copia de seguridad y, en las próximas semanas, esperamos que cada petición nueva de paquete de certificados universales iniciado en una cuenta gratuita, Pro o Business incluya un certificado de copia de seguridad con una clave diferente y emitido por una autoridad de certificación diferente a la del certificado original.
A finales de abril empezaremos a emitir certificados de copia de seguridad para nuestros clientes Enterprise. Si estás suscrito a un plan Enterprise y tienes alguna pregunta sobre los certificados de copia de seguridad, ponte en contacto con tu equipo de cuenta.
Próximamente: Certificados de copia de seguridad para todos
En la actualidad, los certificados universales representan el 72 % de los certificados de nuestra cartera. Pero queremos una cobertura total. Por eso, nuestro equipo continuará desarrollando nuestra cartera de certificados de copia de seguridad para admitir certificados avanzados y certificados SSL para SaaS. En el futuro, también emitiremos certificados de copia de seguridad para los certificados que carguen nuestros clientes con el fin de que puedan tener una copia de seguridad en la que puedan confiar.
Además, seguiremos mejorando nuestra cartera para que la implementación de certificados de copia de seguridad sea instantánea y garantizar así la seguridad y los servicios en línea de nuestros clientes en caso de emergencia.En Cloudflare, nuestra misión es ayudar a mejorar Internet. Con los certificados de copia de seguridad estamos ayudando a mejorar la seguridad y la fiabilidad de Internet ante desastres. ¿Te interesa ayudarnos? ¡Trabaja con nosotros!