Este artículo es parte de la serie “RFCs de IETF” que en forma periódica comentará en idioma español los últimos RFCs publicados, en especial los que tienen relevancia con la operación de TLDs, DNS y dominios.
http://www.rfc-editor.org/rfc/rfc6962.txt
Con la publicación del RFC6962: Certificate Transparency, continúan las reacciones que se han tomado frente a las vulnerabilidades detectadas los últimos años a la infraestructura PKI (Public Key Infrastructure). Los últimos casos de certificados incorrectamente emitidos, duplicados o fraudulentos, han llevado a la creación y adopción de soluciones técnicas que permiten una mitigación del problema, y una reacción rápida ante su ocurrencia.
Si recordamos, uno de los problemas prácticos que se han visto en la infraestructura PKI de certificación en su uso dentro del protocolo TLS, es que un navegador mantiene una lista de Autoridades raíz de certificación, sin mayor control o conocimiento de los certificados finales emitidos. Es de estas Autoridades raíz que emanan las autorizaciones para que un navegador considere confiable una conexión a un sitio web, verificando su identidad digital real. Es así como un navegador, al conectarse a un servicio de Google por ejemplo, como el correo GMail, verifica que el certificado digital presentado haya sido correctamente emitido por una Autoridad de confianza. Hasta ese punto suena todo bien, pero donde comienzan los problemas es cuando otra Autoridad confiable también emite otro certificado para GMail, y un navegador no sabe distinguirlos, por lo que debe aceptar cualquiera de los dos. Y han ocurrido casos, el más notable con la ahora quebrada Autoridad “Diginotar” (http://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates, en inglés), donde queda claro el abuso. Un atacante puede comprometer cualquiera de las Autoridades confiables, y emitirse un certificado para un sitio fraudulento, impersonando a GMail, y por ende, comprometiendo las credenciales de acceso a los correos. Google puede obtener los certificados seguros que quiera desde las Autoridades más seguras que encuentre, pero no puede evitar que cualquier otra Autoridad confiada por los navegadores también pueda emitir (por compromiso de seguridad o por malas prácticas de verificación) otros certificados para Google, sin tener conocimiento.
Se han propuesto muchas mejoras y alternativas de verificación -entre ellas tener un mecanismo de publicación de los certificados reales en el DNS, mantener listas de certificados comúnmente vistos y alertar en caso de ver nuevos, etc-, y este RFC6962 aborda una visión distinta. Se trata de la mantención de un repositorio público de certificados emitidos por todas las Autoridades. Es decir, que sea responsabilidad de las propias Autoridades hacer pública la emisión de un certificado, de tal forma que tanto cada involucrado pueda estar monitoreando si alguien emite un certificado fraudulento a su nombre, como además permitir que los navegadores puedan realizar un chequeo extra cuando se le presente un certificado. Además de realizar las verificaciones obligatorias de una PKI (ver que sea válido hasta una Autoridad raíz de confianza), puede además exigir que aparezca listado en estos repositorios de certificados.
No es casualidad que los tres autores del RFC sean empleados de Google. Ellos han sido de los más involucrados como víctimas, y su permanente desarrollo de soluciones integradas con su navegador Chrome, los hacen estar en una posición privilegiada para ensayar este tipo de infraestructuras. Este RFC6962 en particular es de categoría “Experimental”, lo que quiere decir que no está publicado como estándar, sino que se trata de un etapa de experimentación previa que permita su ensayo y adopción dentro de la comunidad, y evaluar en un futuro convertirse en estándar completo.
El repositorio que define el RFC6962 se trata de una estructura de datos que permite:
Por supuesto el RFC6962 se limita a explicar el funcionamiento de esta estructura de datos y explicar la interacción con él, pero sin entrar en los temas administrativos de mantención, ni materias de establecimiento de la confianza, ni las políticas de bloqueo en los navegadores. Es responsabilidad de cada implementación el decidir qué hacer con la información. Se podría esperar que las primeras Autoridades en incluirse en estas listas lo hagan voluntariamente, para llegar a un punto en que la misma presión de los usuarios de certificados, que van a verse en desventaja si es que no están en los repositorios de certificados transparentes, para que influyan en las Autoridades y que lleguen a publicar todo lo que certifican.
El RFC6962 describe en detalle la estructura de datos, que corresponde a un árbol Merkle (http://en.wikipedia.org/wiki/Merkle_tree, en inglés), con un algoritmo de hashing SHA-256, que cumple con interesantes características de eficiencia, pruebas de consistencia, y firmas del contenido; y también explica su interacción para incluir nuevos certificados (que incluye la entrega de una “estampilla” que confirma la inscripción, que puede utilizarse luego como prueba de su inclusión en el repositorio durante la negociación TLS, y también permite ser capaces de detectar posibles fallas en el repositorio), hasta el protocolo de interacción con los navegadores, a través de transporte HTTP en formato JSON.