Google da un paso para mejorar el ecosistema de Certificate Transparency: No depender de Google

Certificate Transparency (CT), aunque no es muy popular entre los usuarios de a pie, les afecta de muchas formas para mejorar la seguridad de su conexión con las webs.

Es más, les afecta incluso en su privacidad y seguro que no lo estaban teniendo en cuenta. Ahora Google (el principal impulsor de CT) da un paso hacia la independencia del ecosistema aunque todavía debe mejorar sus problemas de privacidad.

¿Qué es Certificate Transparency?

Lo hemos explicado en el pasado, pero resumimos. Si se crea un certificado, debe quedar registrado en unos servidores de Logs públicos. Si no, se sospechará que se ha creado con malas intenciones. Para “registrarlo”, se crea un Signed Certificate Timestamp, o SCT, un token criptográfico firmado que otorga un servidor Log como garantía de que se ha dado de alta el certificado en él.

Este SCT va siempre incrustado en el certificado y cuando se visita una web, el navegador se encarga de comprobar que es válido contra varios servidores logs. Uno de ellos debe ser de Google (hay varias empresas de certificados que tienen logs públicos). Si no es así, aparece un error. Todo esto ocurre sin que el usuario lo perciba.

Un SCT incrustado en el certificado, que el navegador debe comprobar.

Ahora bien, el SCT es más bien una promesa de que se va meter el certificado en el Log, porque nada impide que un operador de un Log (que puede ser cualquiera) se ponga de acuerdo con un atacante, cree un certificado, le otorgue un SCT… pero en realidad no lo haga público en su log. Esto invalidaría todo el ecosistema CT. ¿Cómo lo solucionó Google? Con dos movimientos.

1. Uno es que siempre tenía que haber un “Log de Google” entre los requeridos (actualmente tres) donde se hubiera registrado el certificado. Así, Google se fía de sí misma y sabe que nunca hará el mal, enviando un SCT a un certificado que realmente no ha registrado.
2. Otra, es el “SCT auditing” que implicaría, mal implementado, una clara violación de la privacidad de los usuarios.

Ambas soluciones tienen sus problemas. Veamos por qué.

Chrome mostrando los tres Logs donde el SCT es válido. Uno siempre de Google... hasta ahora.

Al menos un Log de Google

Si Google no se fía del resto de Logs, ¿por qué habría de fiarse los suyos? Pues porque es la mejor solución que encontró en ese momento. Un certificado no se considerará que cumple de forma válida con el ecosistema Certificate Transparency si no está en un Log de Google…. Al menos hasta este mes, donde se ha eliminado esa necesidad.

Se implementará en la versión 100 de Chrome. Cabe recordar que Apple ya fue por su lado con Safari, y en marzo de 2021 anunció que no seguiría esa política de fiarse de Google, que con saber que el SCT estaba en dos logs diferentes, le valía.

La privacidad y el SCT auditing

SCT auditing vino también hace no mucho como una de las soluciones para ese control sobre los SCT y que de verdad los logs se comportasen bien. Es sencillo: auditar aleatoriamente los SCT de los certificados y comprobar que están realmente en los logs. Pero ¿cómo? Pues como mejor sabe Google: usando al usuario y aprovechando la adopción de Chrome para enviar a los Logs los SCT de los sitios que se visitan para comprobar que efectivamente han sido registrados.

Mucho se habló del SCT auditing pero realmente esto suponía un atentado para la privacidad del usuario y un problema al implementarlo. Pero aun así lo hicieron en la versión e Chrome de marzo de 2021 de nuevo, lo mejor que supieron.

¿Cómo? Activaron el SCT auditing solo para los usuarios que ya compartiesen, a través de la compartición de datos mejorada que se puede hacer con Safe Browsing, sus visitas con Google. Al ser algo que los usuarios activaban voluntariamente, se les añadía además como “auditores de SCT” ya de paso. No es la opción por defecto.

Anuncio de cómo funcionaría el SCT auditing

Las dos fórmulas descritas ayudan a controlar que un Log malicioso no emita un SCT para un certificado sin que ese mismo Log lo registre. Pero el SCT auditing debe haberle ido bien a Google, puesto que parece que elimina la primera fórmula y (como ya hacía Safari) desde ahora no se necesita que uno de los Logs sea de Google.

Chrome en Android, el SCT auditing sería solo para quien haya elegido la protección mejorada, no porque mejore su seguridad, sino porque ha elegido compartir más datos con Google

Por tanto, para velar por el buen hacer de los Logs, os quedamos con el SCT auditing donde todos los usuarios que ya comparten ciertos datos de navegación con Safe Browsing, también están velando por un ecosistema CT más seguro a su vez.

Firefox no implementa Certificate Transparency.