Más certificados, más cortos y en cada vez menos tiempo: ¿a dónde va el TLS?

Sergio De Los Santos    2 marzo, 2020
Más certificados, más cortos y en cada vez menos tiempo: ¿a dónde va el TLS?

Son tiempos convulsos para la criptografía. Aunque el usuario de a pie no lo perciba, el mundo de las páginas webs cifradas y autenticadas (aunque no por ello seguras) está atravesando una profunda renovación de todo lo establecido. Algo en principio tan inmutable como la criptografía está pasando por un momento extraño en el que no sabemos cómo acabará. Eso sí, lo que es seguro es que debemos modificar nuestras creencias clásicas sobre cómo funciona la web. Vamos a repasar algunos acontecimientos recientes que van a poner todo patas arriba.

Apple y sus certificados cada vez más “cortitos”

Hace ya tiempo que los navegadores marcan el rumbo de Internet y en concreto de la criptografía. Chrome lleva tiempo en una lucha sin cuartel para terminar con el HTTP e intenta que todo sea HTTPS. Lleva años con la estrategia del “cada vez más”, marcando como inseguras las páginas que no tengan cifrado y autenticación y, a su vez, elevar el estándar de seguridad de las que sí lo tengan. Por ejemplo, dando de lado certificados que usen SHA1. Primero en la hoja, en el intermedio, etc.

Pero esta vez, curiosamente, no fue Chrome sino Apple con Safari el que ha decidido acortar la vida de los certificados a un año, algo que han discutido y votado varias veces todos los implicados. Los navegadores querían que fuese de un año como máximo, las CAs no. Ahora Safari dice que marcará como inválidos los certificados de más de un año a partir de septiembre de 2020.

Los principales actores de Internet y las CAs votaron en septiembre de 2019 si se debía reducir (aún más) el tiempo de vida de los certificados TLS/SSL, obligando a que tuviesen un tiempo de vida máximo. El resultado fue, de nuevo, que no. Un 35% votó a favor de la reducción, entre él Google, Cisco, Apple, Microsoft, Mozilla, Opera y Qihoo360. El resto, sobre todo las CAs, votó en contra, con lo que seguimos oficialmente con los 825 días como máximo de tiempo de vida de los certificados.

Pero en febrero, en el CA/B Forum de Bratislava, Apple anunció que su máximo serán 398 días. Así sin más, sin aviso ni declaraciones al respecto. A partir del 1 de septiembre, marcará como no confiables los certificados creados a partir de esa fecha y cuya vida sea de más de 398 días. ¿Arrastrará esto al resto de navegadores? ¿A la industria en general? Safari, gracias a iPhone, tiene un 18% del mercado, con lo que cuenta con la suficiente popularidad como para empujarlo. A nuestro entender, es una forma de tomar el pulso a su propio liderazgo.

Facebook y sus certificados efímeros

Esencialmente existen tres tecnologías que los navegadores pueden implementar para comprobar el estado de revocación de un certificado digital:

  • La lista negra de revocación descargable, conocida como Certificate Revocation List (CRL), definida en la RFC 5280. La historia ha demostrado que no funciona.
  • OCSP, definido en la RFC 6960. OSCP funciona con un mecanismo de pedido-respuesta que solicita la información sobre un certificado específico a la CA. Lo más efectivo por ahora (sin serlo realmente) es la variante del OSCP Staple obligatorio, pero no es muy usada.
  • CRLSets: es un método “rápido” de revocación que utilizan sólo en Chrome, como ellos mismos dicen, para “situaciones de emergencia”. Son un conjunto de certificados que aglutinan información de otros CRLs, se descargan de un servidor y son procesados por Chrome. Aunque el método es absolutamente transparente, la gestión de qué certificados van en la lista es totalmente opaca y no se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado).

Como nada de esto funciona como debería, nacen las delegated credentials, que suponen realmente acortar a poquísimas horas la vida de los certificados, pero no exactamente, aunque juegan con el concepto de lo efímero para combatir el problema. Lo que hará un servidor es firmar con su certificado pequeñas estructuras de datos válidas por días u horas y delegarlas a los servidores que realmente gestionarán el TLS con el navegador. Es decir, en vez de crear certificados más cortos firmados por la CA intermedia y desplegarlos, se simplifican en una especie de “mini-certificados” firmados por el certificado hoja.

Con la privada del certificado hoja abandonamos toda la complejidad de las CA intermedias y raíz. El sistema delegaría en los servidores front-end esta credencial delegada y, si el navegador lo soporta, la comprobaría antes que el certificado “tradicional”. Si la credencial delegada está firmada por el certificado hoja (tiene la clave pública para comprobarlo), entonces la clave pública en la propia credencial delegada se utiliza para la conexión TLS y no la pública del certificado.

Esta es la clave: se antepone una fórmula mucho más dinámica en caso de revocación que no dependería de ninguna CA y que sería muy rápida de desplegar (tan pronto como caducasen las credenciales delegadas, fuese a por otras y no las pudiera firmar). Además, no hace falta dejar la privada en todos los servidores ni los proxies intermedios. Un único servidor podría servir todas las credenciales delegadas a los servidores web, balanceadores, etc.

Let’s Encrypt y sus certificados cuantiosos

Let’s Encrypt rompió la baraja y ofreció certificados gratuitos y que se podían emitir automáticamente. Su filosofía era ir hacia el “HTTPS everywhere” y no tener que pagar por ello. Su primer certificado nació en septiembre de 2015. En junio 2017 llegó a los 100 millones y el 27 de febrero llegó a los mil millones de certificados.

Eso son muchos certificados y supone claro éxito de la empresa acometida, pero también un pequeño problema para otros proyectos como Certificate Transparency. Si bien no sirve para revocar, sí permite que todos los certificados (fraudulentos o no) deban estar registrados y, por tanto, que sea más sencillo detectar a los fraudulentos y luego revocarlos por los métodos “habituales”.

Certificate Transparency ya nacía con un problema de privacidad, y retrasó su obligatoriedad por varios motivos: implementaciones que no llegaban, cabeceras que se adoptaban con muy poco margen, RFCs que se comenzaban demasiado ajustados… Aun así, Certificate Transparency goza de buena salud (al menos no tan mala como HPKP), sólo que Google ha sido excesivamente ambicioso con la propuesta. Poner de acuerdo a tantos actores es complicado; más aún en un entorno tan crítico como el de la seguridad TLS. Además ahora se enfrenta a un crecimiento demencial que puede complicar la infraestructura.

Certificate Transparency Log Growth
Fuente: sslmate.com

Algunos logs de Certificate Transparency ya se acercan a los mil millones de certificados. Para gestionar mejor este sistema que pretende abarcarlo todo y ser read only, terminaron creando logs por años. Los certificados que expiran en esos años se meten en servidores de logs diferentes que después, normalmente, ya no reciben más certificados.

Fuente: sslmate.com

Pero si tomamos, por ejemplo, los servidores de Google Argon 2019 (ya casi estable en 850 millones de certificados en todo 2019) y lo comparamos con Argon 2020, vemos que este último tiene en sólo dos meses 400 millones, casi la mitad que el anterior. A este ritmo, llegaría a los 2400 millones de certificados (si no más) gracias precisamente, al crecimiento de Let’s Encrypt y a la política de certificados cada vez más cortos.

Fuente: sslmate.com

¿Cómo va a encajar todo esto en el ecosistema TLS del futuro? Iremos viéndolo poco a poco.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *