- Let’s Encrypt cambiará a una cadena de certificados más corta que termina en ISRG Root X1 y no extenderá la firma cruzada (cross-sign) que vence el 30 de septiembre de 2024
- En sus primeros años dependió de DST Root CA X3 de IdenTrust porque su propia raíz aún no era suficientemente confiable, pero ahora el alcance de confianza de ISRG Root X1 se ha ampliado mucho
- La firma cruzada de la raíz que se añadió en 2021 para mantener la compatibilidad con Android antiguos fue una medida temporal, y gracias a ella los dispositivos Android viejos pudieron seguir confiando en los certificados de Let’s Encrypt durante 3 años más
- En los últimos 3 años, la proporción de dispositivos Android que confían en ISRG Root X1 subió de 66% a 93.9%, y al eliminar la firma cruzada también se reduce en más de 40% la cantidad de bytes de certificados en el handshake TLS
- A los usuarios de Android 7.0 o anterior se les recomienda usar Firefox Mobile, y los operadores de sitios y autores de clientes ACME deben revisar el manejo de cadenas según el calendario de transición de 2024
Antecedentes del fin de la firma cruzada
- En sus primeros años, Let’s Encrypt hizo que su certificado intermedio fuera firmado de forma cruzada por DST Root CA X3 de IdenTrust para que sus certificados fueran ampliamente confiables
- Era una forma de lograr que se confiara en los certificados emitidos por ese intermedio aunque su propia raíz, ISRG Root X1, todavía no fuera ampliamente confiable
- Con el paso del tiempo, ISRG Root X1 llegó a ser ampliamente confiable por sí misma
- A finales de 2021, estaba previsto que vencieran tanto el certificado intermedio con firma cruzada como DST Root CA X3
- En ese momento, los navegadores modernos ya confiaban en la raíz de Let’s Encrypt, pero más de un tercio de los dispositivos Android seguían usando versiones antiguas del sistema operativo
- Esos dispositivos podían dejar de confiar de repente en los sitios web que usan certificados de Let’s Encrypt
- En 2021, Let’s Encrypt aplicó una firma cruzada directamente a la raíz en lugar de al certificado intermedio, como medida temporal que durara más que DST Root CA X3
- Gracias a eso, los dispositivos Android antiguos pudieron seguir confiando en los certificados de Let’s Encrypt durante 3 años más
- Esa firma cruzada vence el 30 de septiembre de 2024
Por qué cambia a una cadena más corta
- Let’s Encrypt ya no obtendrá una nueva firma cruzada para extender la compatibilidad
- En los últimos 3 años, la proporción de dispositivos Android que confían en ISRG Root X1 subió de 66% a 93.9%
- Android 14 puede actualizar el almacén de confianza sin una actualización completa del sistema operativo, por lo que esta proporción podría aumentar aún más
- Eliminar la firma cruzada reduce en más de 40% la cantidad de bytes de certificados transmitidos en el handshake TLS
- También reduce mucho los costos operativos, lo que permite a Let’s Encrypt concentrar recursos en mejorar la privacidad y la seguridad
Calendario de transición de 2024
- Jueves 8 de febrero de 2024: se dejó de ofrecer por defecto la firma cruzada en las solicitudes al endpoint de API
/acme/certificate- Para la mayoría de los suscriptores, esto hizo que el cliente ACME configurara una cadena que termina en ISRG Root X1 y que el servidor web ofreciera la cadena más corta durante el handshake TLS
- La cadena más larga que termina en la firma cruzada próxima a vencer todavía podía solicitarse como cadena alternativa
- Jueves 6 de junio de 2024: se dejó de ofrecer por completo la cadena más larga con firma cruzada
- Fue un poco más de 90 días antes del vencimiento de la firma cruzada, equivalente a la vida útil de un certificado
- El calendario se definió para asegurar al menos un ciclo completo de emisión para que los suscriptores dejaran de depender de la cadena con firma cruzada
- Lunes 30 de septiembre de 2024: vence el certificado con firma cruzada
- Para la mayoría de los usuarios no debería ser un evento especial, y cualquier falla de cliente ya debería haberse manifestado en los 6 meses anteriores
Qué deben revisar usuarios y operadores
- Los usuarios de Android 7.0 o anterior pueden necesitar tomar medidas para seguir accediendo a sitios web protegidos con certificados de Let’s Encrypt
- Let’s Encrypt recomienda instalar y usar Firefox Mobile, que usa su propio almacén de confianza en lugar del almacén de confianza del sistema Android
- Los operadores de sitios deben revisar las estadísticas de uso del sitio web y las cadenas user-agent activas durante el segundo y tercer trimestre de 2024
- Si las visitas desde Android caen de repente, es posible que haya una cantidad importante de usuarios con Android 7.0 o anterior
- Se recomienda orientar a esos usuarios para que usen Firefox Mobile
- Los autores de clientes ACME deben descargar e instalar correctamente la cadena de certificados que entrega la API en cada emisión y renovación de certificado
- Entre las fallas observadas en el pasado hubo casos en los que no se descargó la cadena en absoluto y solo se entregó el certificado end-entity
- También hubo casos en los que se entregó una cadena hardcodeada sin descargar la cadena
- Y otros en los que la cadena se descargó solo en la primera emisión y no volvió a descargarse durante las renovaciones
- Las preguntas sobre esta transición pueden hacerse en el community forum de Let’s Encrypt
1 comentarios
Opiniones de Hacker News
Recuerdo que Let's Encrypt había anunciado que haría esta transición en el verano de 2019 y luego la pospuso tras escuchar el feedback de la comunidad.
En ese momento fui una de las personas que pidió con fuerza que lo reconsideraran, pero no imaginé que en este asunto fueran a superar tanto las expectativas y retrasarlo 4 años y medio. Gracias por tratar el ecosistema TLS con tanto cuidado.
Para cubrir el 95% de los dispositivos Android hay que dar soporte hasta Android 7.0 Nougat, de agosto de 2016.
https://en.wikipedia.org/wiki/Android_Nougat
Para cubrir el 95% de los dispositivos iOS basta con iOS 14, de septiembre de 2020, y si miramos solo el 90%, en Android es 8.1 (2017) y en iOS es 15 (2021).
https://iosref.com/ios-usage
https://en.wikipedia.org/wiki/IOS_14
Parece que Apple hace mejor el trabajo de convencer o permitir que la gente pase a sistemas operativos más recientes.
La razón por la que los dispositivos no se actualizan es que los fabricantes dejan de ofrecer actualizaciones.
Según la página del paquete de CA de curl, el paquete de Mozilla pesa unos 200 KB descomprimido, y en mi Android la app de Chrome pesa 25 MB, así que mantenerlo actualizado con un aumento del 1% en el tamaño de la app parece razonable.
Claro que otras apps también podrían querer CA actualizadas, pero también vale la pena preguntarse si necesitan todas las CA o solo las que realmente es probable que usen.
Google no puede hacer mucho si algún fabricante barato decide no actualizar a sus clientes. Puede exigir que ofrezcan actualizaciones durante cierto tiempo para obtener o mantener la certificación de Android, pero en algún momento ese fabricante podría abandonar Android por completo.
Además, Qualcomm tampoco ofrece kernels y blobs actualizados para chipsets antiguos después de un tiempo. Google negoció para que extendieran eso más allá de los lamentables 18 meses de antes, pero Qualcomm no tiene obligación de colaborar más. Desde que Google empezó a fabricar sus propios chipsets, su interés en este problema también disminuyó un poco.
No digo que esté bien, pero dado el modelo de Android, en general esto es lo que termina pasando, y el modelo de Apple le permite controlar más estas partes.
Me pareció bastante interesante la forma en que lograron que la antigua firma cruzada siguiera funcionando.
La nueva firma cruzada era algo inusual porque seguía vigente después de la expiración de DST Root CA X3. Fue una solución posible porque Android, de forma intencional, no exige la fecha de expiración de los certificados que se usan como anclas de confianza.
En realidad, las anclas de confianza se comportan de forma bastante distinta a otros certificados, lo que puede resultar sorprendente.
[1] https://letsencrypt.org/2020/12/21/extending-android-compati...
[2] https://alexsci.com/blog/name-non-constraint/
Si mal no recuerdo, uno de los grandes problemas fue que versiones antiguas de OpenSSL sí verificaban la expiración del ancla raíz. Y eso no fue todo: en la empresa donde trabajaba, Ubuntu tuvo que parchear algo para manejar esta situación, y el parche salió apenas unos días antes de la expiración, por lo que algunos sistemas sufrieron una breve interrupción. Tuvimos que reconstruir una gran cantidad de imágenes Docker para solucionar el problema.
Creo que usaron esta solución alternativa porque era tan radical y sin precedentes, pero la diferencia de costo frente a obtener una firma cruzada de una raíz no expirada y ampliamente compatible era enorme. También debe haber requerido una cantidad enorme de pruebas. No fue perfecta, pero fue impresionante que en general todo pasara sin mayores sobresaltos.
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
Pero al buscarlo, resulta que en la práctica funciona sin la línea 5, por lo que todas las verificaciones de tiempo se hacen contra la hora actual. Todos los certificados de la cadena deben ser válidos ahora.
Los certificados de firma de código funcionan de la forma en que yo pensaba que también funcionaría TLS. El código con timestamp sigue siendo válido aunque el certificado raíz haya expirado, siempre que la raíz fuera válida en el momento del timestamp.
Espero que el vencimiento del certificado de firma cruzada no sea nada para la mayoría, pero el vencimiento de la firma cruzada de DST anterior no fue así
Según recuerdo, GnuTLS no pudo construir correctamente la ruta después del vencimiento. Parece que solo construía una ruta hacia el certificado vencido, informaba que estaba vencido y se detenía ignorando otras rutas posibles
Lo peor es que GnuTLS era la biblioteca TLS que se usaba cuando apt usaba HTTPS. HTTPS no era el valor predeterminado, pero nuestro equipo de seguridad quería venderizar todos los paquetes y ofrecerlos de forma segura, lo cual en sí era razonable, pero el costo fue una interrupción. Creo que se arregló en Bullseye y, por pura suerte, fue apenas una semana antes del vencimiento. Azure también sufrió varias interrupciones relacionadas con ese vencimiento
Además de usar HTTP sin cifrar, ¿hay alguna solución propuesta para que TLS deje de ser el componente más frágil de la web?
Los cambios constantes como descartar protocolos, vencimientos de certificados y reemplazos parecen haber llevado demasiado lejos la obsolescencia programada
La parte mala que lleva a la obsolescencia programada es que los dispositivos dejan de recibir actualizaciones del fabricante demasiado rápido y tampoco pueden ser actualizados por terceros
Mi solución preferida sería una ley que diga que, si un fabricante tiene que dejar de producir actualizaciones de seguridad antes de que se cumplan 10 años desde el fin de venta, o quiere hacerlo, entonces debe publicar todo como open source o permitir que todos los compradores reciban un reembolso total
La razón para hacerlo es que la revocación distribuida a escala mundial es un problema absurdamente difícil. Para mitigar que algunas combinaciones de usuarios y certificados sean en la práctica imposibles de revocar, se reduce la vida útil de los certificados para limitar el alcance del daño
Claro que no es un gran consuelo, pero el mundo de certificados de corta duración posterior a ACME ofrece una mejor experiencia para desarrolladores que el mundo de pesadilla de los certificados Verisign de largo plazo. Vale la pena recordar que cualquier alternativa a TLS inevitablemente enfrentaría problemas similares
El formato de certificados x509, en la práctica, no ha cambiado durante mucho tiempo
Los cambios de protocolo probablemente se estabilicen ahora. TLS 1.2 se introdujo en 2008 y todavía se considera aceptable, así que ya es difícil verlo como algo nuevo. Mucha gente lo ha examinado de cerca, así que espero que la mayoría de los problemas hayan salido a la luz
En mi opinión, lo que hace Let's Encrypt podría verse básicamente como DANE, así que me pregunto por qué no simplemente darle soporte. Por supuesto, puede haber casos de uso en los que DANE no sea adecuado
No veo por qué lo perfecto debería impedir algo suficientemente bueno, y quienes quieran usar DANE deberían poder hacerlo
Cuando dicen que “puede reducir mucho los costos operativos y concentrar fondos en mejorar la privacidad y la seguridad”, ¿eso significa que están pagando sumas como millones de dólares por la firma cruzada?
Ese mismo año los gastos totales fueron de 5,1 millones de dólares, así que este gasto equivale a casi el 10% del presupuesto
[0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...
¿Alguien conoce la historia de fondo de cómo una empresa de certificados terminó dándoles una firma cruzada? ¿Let’s Encrypt no destruye por completo su modelo de negocio?
Empresas como RapidSSL o GoDaddy no habrían firmado de forma cruzada a Let’s Encrypt salvo que les ofrecieran una suma del nivel de “cómprennos todo nuestro negocio de CA”
Pero vender certificados DV no era el modelo de negocio de IdenTrust, así que, como se estimó en otros lados, podrían haber estado dispuestos a ofrecer la firma cruzada por un monto de menos de seis cifras. Por cómo funcionan los certificados raíz de TLS, la firma cruzada de IdenTrust le resultaba a LE tan útil como la de una CA súper rentable
Tampoco parece que IdenTrust haya quebrado
1 IdenTrust 48.5% 53.6%
2 DigiCert Group 13.1% 14.5%
3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
4 GlobalSign 6.1% 6.7%
5 Let's Encrypt 5.8% 6.4%
6 GoDaddy Group 4.8% 5.3%
https://en.wikipedia.org/wiki/Certificate_authority
Cuando a fines de 2021 expiraron el certificado intermedio con firma cruzada y el propio DST Root CA X3, todos los navegadores modernos ya confiaban en la raíz de LE, pero más de un tercio de los dispositivos Android seguían usando sistemas operativos antiguos, así que existía el riesgo de que de pronto no confiaran en sitios web que usaban certificados de LE.
Recién me enteré hace unas semanas, pero parece que los usuarios de Ubiquiti también se vieron afectados.
Hace poco, al mover el backend de AWS a un servidor local, tuve que cambiar de Letsencrypt, que usaba normalmente, a ZeroSSL.
Fue porque un equipo IoT de 2016 que todavía recibe soporte no tenía el certificado raíz necesario para validar certificados de LE. Probablemente estaba relacionado con la expiración en 2021 del certificado raíz R3 que usaba LE.
Me impactó bastante que la expiración de un solo certificado pudiera convertir en ladrillos todos los productos vendidos. En este caso no fue un gran problema, porque existía un certificado raíz válido de otro proveedor.
Incluso siguieron emitiéndolos después de la fecha fijada por el CA/Browser Forum. En ese momento pensé que todos habían entendido que usar Web PKI sin tener una forma de enviar actualizaciones era incompatible, pero parece que no.
Desde poco después de que se introdujera la firma cruzada, venía eliminando los certificados con firma cruzada en sitios orientados a escritorio.
Porque aparecieron problemas de compatibilidad que antes no existían, y algunos verificadores de certificados tropezaban con certificados raíz vencidos. Como los usuarios afectados no eran técnicos, nunca pude averiguar la causa raíz.