¿Qué es una lista de revocación de certificados (CRL) frente a OCSP?

La revocación de certificados es una función importante, y a menudo olvidada, de la gestión del ciclo de vida de los certificados. En este blog, exploraremos las funciones clave de la revocación de certificados, incluidas las listas de revocación de certificados (CRL), el protocolo de estado de certificados en línea (OCSP) y el grapado OCSP.

Los certificados digitales se utilizan para generar confianza en las transacciones en línea. La doble función de los certificados -cifrar las comunicaciones y autenticar la identidad del propietario del certificado- constituye la base de la Infraestructura de Clave Pública (PKI).

Cada certificado tiene también un periodo de validez finito, que a partir^{del 1 de} septiembre de 2020 será de 13 meses. Sin embargo, durante ese periodo de validez, el propietario de un certificado y/o la autoridad de certificación (CA) que lo emitió puede declarar que ya no es de confianza. En estos desafortunados casos, es necesario revocar los certificados no fiables e informar a los usuarios. Esto se hace añadiendo el certificado no fiable TLS/SSL a una Lista de Revocación de Certificados (CRL).

He aquí un ejemplo de aviso de certificado revocado SSL/TLS en Google Chrome(Fuente de la imagen)

La revocación de certificados es un componente de vital importancia del ciclo de vida de los certificados. Hay muchas definiciones de lo que es una CRL, pero si lo desglosamos de forma sencilla, una CRL contiene una lista de certificados revocados: básicamente, todos los certificados que han sido revocados por la CA o el propietario y en los que ya no se debe confiar.

El Consejo de Seguridad de CA define una CRL como "un archivo firmado digitalmente que contiene una lista de certificados que han sido revocados y aún no han caducado". La firma digital de los archivos CRL por parte de las CA emisoras es importante para demostrar la autenticidad del archivo y evitar su manipulación.

RFC 5280 describe una CRL como "una estructura de datos firmada y con fecha y hora que una autoridad de certificación (CA) o emisor de CRL emite periódicamente para comunicar el estado de revocación de los certificados digitales afectados".

Dependiendo de las políticas internas de la CA, las CRL se publican periódicamente, ya sea cada hora, cada día o cada semana. El estado de un certificado en la CRL puede ser "revocado", cuando ha sido revocado de forma irreversible, o "retenido", cuando no es válido temporalmente.

El formato de una CRL se define en el estándar X.509 y en el RFC 5280. Cada entrada de una lista de revocación de certificados incluye la identidad del certificado revocado y la fecha de revocación. La información opcional incluye un límite de tiempo, si la revocación se aplica durante un periodo de tiempo específico, y un motivo para la revocación.

Los certificados contienen una o varias URL desde las que el navegador o la aplicación pueden recuperar la respuesta CRL. Cuando un navegador inicia una conexión TLS a un sitio, se valida el certificado digital del servidor y se comprueba si hay anomalías o problemas.

Durante este proceso de validación, el navegador web comprueba si el certificado figura en la CRL emitida por la CA correspondiente. Dependiendo del estado del certificado del servidor, el navegador creará una conexión segura o alertará al usuario sobre el certificado revocado y el riesgo de continuar con una sesión no cifrada.

Comprobar las CRL es un paso esencial en una transacción basada en PKI, ya que verifican la identidad del propietario del sitio y descubren si el certificado asociado es de confianza.

A continuación se ilustra el flujo de trabajo del proceso de comprobación de revocación de certificados mediante CRL

Cuando una aplicación o navegador comprueba el estado de revocación de un certificado, recupera la CRL actual de un punto de distribución de CRL (CDP) especificado. Un CDP es la ubicación en un servidor de directorio LDAP o servidor web donde una CA publica las CRL.

Una vez recuperada la CRL, suele almacenarse en caché hasta que la propia CRL caduca. El CDP debe estar accesible en todo momento para garantizar que los dispositivos o aplicaciones puedan recuperar la nueva CRL cuando sea necesario. De lo contrario, no será posible determinar el estado del certificado en cuestión, y las comprobaciones del estado de revocación del certificado fallarán.

Los certificados digitales se revocan por muchas razones y hay muchos ejemplos recientes de revocaciones masivas de certificados. Entre los motivos de revocación de certificados se encuentran los siguientes:

• La CA descubre que ha emitido un certificado de forma indebida y errónea
• Se cree o se descubre que un certificado es fraudulento.
• La clave privada de un certificado ha sido comprometida
• La CA emisora ha sido comprometida
• El propietario del sitio web cesa su actividad y deja de ser propietario del nombre de dominio o del servidor definido en el certificado.
• Durante la autenticación y validación del sitio web, el solicitante falsea alguna información utilizada en el proceso, o el propietario del sitio web ha incumplido los términos de su acuerdo con la AC.

Sea cual sea el motivo por el que se revoque un certificado, las CRL son importantes para proteger a los usuarios de ataques de intermediario o de la comunicación con un sitio fraudulento que se hace pasar por uno legítimo. Sin las CRL, los usuarios se enfrentarían a numerosos riesgos de seguridad y privacidad, como:

• Filtración de información personal o sensible. Un atacante que realice un ataque man-in-the-middle puede ser capaz de interceptar la información personal y sensible que el usuario introduce en un servidor web. Esta información podría ser números de la Seguridad Social, datos de cuentas bancarias, números de tarjetas de crédito, datos médicos, etc.
• Robo de identidad y suplantación. Un malhechor podría capturar las credenciales de identidad que el usuario introduce para autenticarse en un servidor web. El robo y compromiso de credenciales es una razón clave para los ataques de suplantación de identidad o las campañas de compromiso de correo electrónico empresarial (BEC). Además, los delincuentes podrían utilizar estas credenciales para secuestrar la cuenta del usuario.
• Pérdidas económicas. Con la información bancaria, de tarjetas de crédito y credenciales robadas, el ciberdelincuente está a sólo un paso de robar el dinero del usuario.
• Instalación de malware. Acceder a un sitio web inseguro es una forma de que los delincuentes instalen malware en el ordenador de la víctima. Este malware se utiliza después para robar información personal, ejecutar keyloggers o secuestrar el ordenador para formar parte de un ataque DDoS mayor. La instalación de malware también puede tener una motivación económica utilizando una variante de ransomware y cifrando todos los datos del ordenador del usuario.

A pesar de la importancia de mantener una CRL actualizada, el proceso no es impecable. Aunque cada CA emite una CRL independiente, el archivo puede llegar a ser bastante grande, lo que las hace ineficientes para su uso en dispositivos con memoria limitada, como smartphones o dispositivos IoT .

Cuando una CA recibe una solicitud de CRL de un navegador, devuelve el archivo completo con los certificados revocados de esa CA. A continuación, el navegador debe analizar la lista para determinar si el certificado solicitado ha sido revocado o no. Dependiendo del tamaño del archivo, el proceso puede provocar latencia y bajo rendimiento para los usuarios de la web.

Otro problema es que si el cliente no tiene una copia "convenientemente reciente" de la CRL, tiene que buscar una durante la conexión inicial al sitio, lo que puede hacer que la conexión dure más tiempo.

Lo cierto es que el mantenimiento de las CRL no es apropiado para publicar y distribuir información crítica en tiempo casi real. Dado que los navegadores almacenan en caché las CRL para evitar la sobrecarga computacional, puede darse una ventana temporal en la que se acepte un certificado revocado, lo que crea riesgos para la privacidad y la seguridad de los usuarios.

Otro método utilizado para transmitir información a los usuarios sobre certificados revocados es el Protocolo de Estado de Certificados en Línea (OCSP). En lugar de descargar la última CRL y analizarla para comprobar si un certificado solicitado está en la lista, el navegador solicita el estado de un certificado concreto al servidor de revocación de la CA emisora.

Utilizando el número de serie del certificado, el servicio OCSP comprueba el estado del certificado y, a continuación, la CA responde con una respuesta firmada digitalmente que contiene el estado del certificado. Una respuesta OCSP contiene uno de estos tres valores: "bueno", "revocado" o "desconocido". Las respuestas OCSP son más pequeñas que los archivos CRL y son adecuadas para dispositivos con memoria limitada.

A continuación se ilustra el flujo de trabajo del proceso de comprobación de revocación de certificados mediante OCSP

El grapado OCSP es una mejora del protocolo OCSP estándar y se define en el RFC 6066. Activar el grapado OCSP elimina la necesidad de que un navegador envíe solicitudes OCSP directamente a la CA. En su lugar, el servidor web almacena en caché la respuesta OSCP de la CA y cuando el cliente inicia un handshake TLS , el servidor web "grapa" la respuesta OSCP al certificado que envía al navegador.

A continuación se ilustra el flujo de trabajo del proceso de comprobación de revocación de certificados mediante el grapado OCSP

El grapado OCSP presenta varias ventajas

• Mejora del rendimiento, ya que el navegador recibe el estado del certificado del servidor cuando lo necesita, evitando la sobrecarga de comunicarse con la CA emisora.
• Mayor seguridad, al minimizar los casos de falsos positivos y reducir el número de vectores de ataque.
• Mayor privacidad del usuario, ya que las CA sólo reciben solicitudes de sitios web y no de usuarios.

Si una CA deja de funcionar, no podrá emitir nuevos certificados, pero si su CRL caduca o es inaccesible, todos sus certificados quedarán inmediatamente inutilizables. Como ya se ha comentado, la mayoría de las aplicaciones necesitan comprobar la validez de los certificados con un servidor CRL u OCSP. Si no pueden llegar al CDP o al respondedor OCSP, o si la propia CRL está caducada, los usuarios no podrán acceder a su aplicación.

La supervisión continua y en tiempo real de las revocaciones que ofrecen las herramientas de automatización del ciclo de vida de los certificados, como Keyfactor Command , puede garantizar que esto no ocurra (véase el vídeo a continuación).

La revocación eficaz y eficiente de certificados falsos, comprometidos o no fiables refuerza la seguridad y la privacidad de millones de transacciones en línea cada día. Las organizaciones necesitan automatizar y gestionar de forma centralizada sus certificados digitales para evitar costosas interrupciones o ataques debidos a la revocación o caducidad de los certificados.

Keyfactor Command le permite gestionar el ciclo de vida de las claves y los certificados digitales en toda su empresa y obtener visibilidad desde la detección y supervisión de certificados hasta su emisión, renovación y revocación. Vea nuestras demostraciones a la carta para obtener más información sobre nuestra plataforma integral de automatización del ciclo de vida de certificados y PKI.