Desencuentros en el mundo de los certificados y las CA: Google contra el mundo

Sergio De Los Santos    16 septiembre, 2019
Desencuentros en el mundo de los certificados y las CA: Google contra el mundo

Ninguna industria se libra de miserias internas, peleas y desencuentros entre sus principales actores. En estos días, (o meses, o años) la industria de los certificados digitales se transforma profundamente e intenta adaptarse a los nuevos tiempos. Actores como Google marcan el paso ahora más que nunca gracias al control de Chrome (donde deciden cuándo y cómo gestionar las alertas hacia el usuario, por ejemplo) o iniciativas como Certificate Transparency. Y precisamente vamos a centrarnos en dos encontronazos recientes de Google con personajes de la industria.

En ambos casos el desencuentro ha involucrado a Ryan Sleevi, empleado de Google conocido por sus innumerables aportaciones en el mundo de la criptografía y certificados en general. Más a allá de la curiosidad, estas discusiones cuentan con buenos argumentos por ambas partes, y suponen una excusa interesante para la reflexión.

El caso Ballot SC22

Los principales actores de internet (Google, Microsoft, Apple, Mozilla…) y las CAs ya han votado si se debe reducir (aún más) el tiempo de vida de los certificados TLS/SSL obligando a que tengan un tiempo de vida máximo.

En los 2000, no existía límite para el tiempo de vida de un certificado. En 2012 se impuso un límite de 5 años. En 2015 se redujo a 3 años máximo. En 2017 Google intentó reducirlo 368 días (poco más de un año) pero se votó en contra. Poco después se votó a favor de 825 días (algo más de dos años). En septiembre de 2019 se ha votado que la duración sea de 397 días. Esta nueva propuesta viene otra vez principalmente impulsada por Google, Mozilla, Apple y Let’s Encrypt. Google lleva tiempo queriendo reducir el tiempo de vida de los certificados e impulsando iniciativas para mejorar su seguridad en varios aspectos. Desde una notificación más agresiva al usuario (haciendo pasar por no seguros los hashes obsoletos, las páginas sin HTTPS, etc) hasta sistemas complejos como Certificate Transparency.

La  votación SC22 suponía que la acortar del tiempo de vida representa una mejora en la seguridad en varios planos: supuestamente, adaptarse más rápido a los cambios (por ejemplo al abandonar algoritmos que vayan quedando obsoletos, introducción de nuevos campos en los certificados…); paliar el sistema de revocación (CRL y OSCP), que sigue sin funcionar y está totalmente roto; fomentar la automatización de los procesos (por realizarse más frecuentemente) y por tanto, con menor posibilidad de fallos.

Pero todo esto es discutible. Las CAs Entrust Datacard y Globalsign no están convencidas de sus hipotéticas ventajas. Aparte de contar con el respaldo de sus clientes para el rechazo, alegan que no se ha hecho ningún estudio al respecto y todo son hipotéticas ventajas. Es lógico que los clientes no quieran certificados más cortos: implica más procedimientos, gastos y problemas en general. Si no se popularizan sistemas como ACME para automatizar la renovación y despliegue de certificados, los administradores se mostrarán siempre reacios. Let’s Encrypt ofrece certificados gratuitos y ya permite renovación automática de serie. Sin esos problemas, no es casualidad que apoye sin fisuras la propuesta de acortar certificados. A los navegadores tampoco les afectan estos problemas.

En la lista de correo, Doug Beattie y Ryan Sleevi  de Google se enzarzaron en una discusión abierta durante la votación. Beattie defendía que no había estudios que avalaran la necesidad de acortar la vida de los certificados, frente a los costes que suponía. No existían pruebas de que disminuirían el número de incidentes si se acortara el periodo de validez. Sleevi explicaba que la propuesta en sí era una explicación suficiente y que del mismo modo, habría que explicar si acortar la vida suponía algún daño, además de mostrar numerosos ejemplos. Merece la pena leer los argumentos de uno y otro, donde en algunos puntos rozaba una en cierta profundidad filosófica más general: ¿recordar incidentes a los clientes y proponer modificaciones para su mitigación sirve para convencer del cambio de manera constructiva, o para intimidar a la comunidad?

Por cierto, el resultado de la votación es que no se acorta la vida de los certificados.

El caso Scott Helme

En esta entrada Scott Helme realiza una pequeña investigación sobre certificados EV (Extended Validation). Se supone que son más caros y que la validación sobre quién los solicita y los datos que se emiten en ese certificado deben ser totalmente rigurosas y fehacientes. Cynthia Revströn encontró un certificado de una compañía sueca con un número danés en el certificado. No es grave, pero implica que quizás no se están siguiendo las normativas de los certificados EV a rajatabla. Con esta excusa, Helme decide buscar otros certificados con, potencialmente, ese u otros tipos de problemas que violen el estándar EV. Encuentra unos 4000. Estos deben ser reportados y revocados. Estima que a 250 dólares cada uno, ha revocado un millón de dólares en certificados.

Ryan Sleevi vuelve a la carga en Twitter y se enzarza en la polémica. Alega que ese tipo de investigaciones no aporta ningún valor, y su razonamiento es que estos fallos puntuales solo saturan el sistema. Ahora todos ellos deben ser revocados, pero no aporta nada concreto que motive y proponga una mejora a largo plazo. No son fallos sistemáticos a los que se les pueda poner remedio sino “anecdóticos” y por tanto hacen más daño que bien.

Pone ejemplos positivos de fallos sistemáticos como este estudio en el que se monitorizan errores y fallos de certificados desde 2012, y desde donde se ayuda a la industria a mitigarlos a gran escala. Pone otro buen ejemplo como el encontrado por Corey Bonnell , que descubrió que Apple y Google, habían emitido 12 millones de certificados con 63 bits en su número de serie, no 64. Esto era relevante y curioso. El programa EJBCA que genera certificados sacrificó un bit para que el entero aleatorio que representa el número de serie siempre fuera positivo. Ahora bien, se exige una entropía y aleatoriedad de 64 bits en los números de serie de certificados para no facilitar los ataques de colisión que ya se conocen por culpa de MD5 y SHA1. Si se hicieran como “antiguamente”, números pequeños y correlativos, se facilita a un atacante la construcción de una parte de un hipotético certificado falso. Con 63 bits, baja la entropía y no se sigue el estándar. En realidad afecta poco, porque 63 es suficiente y además ya pocos usan MD5 y SHA1. Pero fue una llamada de atención interesante para la industria.

Sirviéndose de estos ejemplos, Sleevi finalmente se rendía sin estar convencido en la discusión ante Helme, que defendía la postura de que este estudio también ayuda a poner foco en que la industria debe tomarse en serio en general la emisión de certificados EV, aunque cada uno de los 4000 suponga un problema diferente.

¿Quién tiene razón en cada caso? ¿Son estas controversias de Sleevi (representando a Google) necesarias para hacer avanzar la industria? Es como preguntar quién tiene razón en el caso del eterno debate del “full disclosure”. Lo importante es escuchar a todas las partes si defienden con motivos sólidos cada postura.

Comentarios

  1. Bueno, quizás es una afirmación un poco radical. Si “buscas por ahí” es una opinión generalizada el hecho de que los mecanismos de revocación actuales carecen de la agilidad necesaria. En concreto, cuando ha habido grandes desastres que han requerido revocaciones masivas (tipo HeartBleed), el sistema no ha estado a la altura.

    En concreto el CRL nació roto, por inmantenible, y el OSCP que vino a mejorarlo, también ha tenido sus problemas, parcheos y sobre todo, poca popularidad. Tanto, que incluso Chrome tiene su propio sistema de revocación “a su bola”. En fin, que no son técnicas que hayan conseguido solucionar el problema de raíz.

Deja un comentario

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