Delegated credentials, la nueva fórmula para mitigar la revocación de certificados

¿Hemos mencionado alguna vez que la gestión de los certificados TLS es un problema que no está resuelto? Seguro que sí. Por si no queda claro, en los últimos años, además de la fórmula tradicional de revocación de certificados (las CRL, certificate revocation lists), se han puesto en marcha numerosas propuestas: desde OCSP con sus variantes a CRLSets, incluso Certificate Transparency que no revoca pero sirve para detectar rápidamente certificados fraudulentos hasta la reciente votación para acortar su vigencia. Ahora aparece una nueva fórmula auspiciada por Facebook: las “delegated credentials”, que analizamos en este artículo.

Por qué una nueva fórmula

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) definido en la RFC 5280. La CRL es una lista de números de serie de certificados revocados que se descarga en un intervalo fijo de tiempo. 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 efecitvo por ahora (sin serlo realmente) es la variante del OSCP Staple obligatorio, pero no es muy usado.
CRLSets. Es un método “rápido” de revocación que utiliza solo Chrome, como ellos mismo dicen, para “situaciones de emergencia”. Son un conjunto de certificados que se aglutinan de 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, no se sabe con qué certificados lo actualizan (a menos que se averigüe por otro lado).
Certificate Transparency. Si bien no sirve para revocar, permite que todos los certificados (fraudulentos o no) deban estar registrados y por tanto, sea más sencillo detectar a los fraudulentos y luego revocarlos por los métodos “habituales”.
Acortación de la vida. Visto que es imposible revocar a tiempo, la técnica preventiva es que los certificados dispongan de un menor tiempo de vigencia. La reciente votación SC22 suponía que acortar el 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, etc.); 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. El resultado de la votación fue que no se acorta la vida de los certificados.

Crecimiento en los últimos años de los CRL (Certificate revocation lists) hasta el pico en 2014 a causa de HeartBleed
Fuente: https://isc.sans.edu/forums/diary/Heartbleed+CRL+Activity+Spike+Found/17977

Delegated credentials

Supone realmente acortar a poquísimas horas la vida de un certificado, pero no exactamente, aunque juega 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 delegarla a los servidores que realmente gestionarán el TLS con el navegador. O sea, en vez de crear certificados más cortos, firmados por la CA intermedia y desplegarlos, se simplifica a una especie de “mini-certificados” firmados por el certificado hoja. Sí, habéis oído bien.

Lo que se firma realmente es esta estructura como esta:

Con la privada del certificado hoja, abandonamos así 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, no la pública del certificado. Esta es la clave, se antepone una formula 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 proxis intermedios. Un único servidor podría servir todas las credenciales delegadas a los servidores web, balanceadores, etc.

Así que este será el método que veremos cada vez con mayor frecuencia, porque será adoptado como estándar por la IETF.