La revocación de certificados es una función importante, y a menudo pasada por alto, de la gestión del ciclo de vida de los certificados. En este blog, exploraremos las funciones clave de la revocación de certificados, incluyendo las listas de revocación de certificados (CRL), el Protocolo de Estado de Certificado en Línea (OCSP) y el OCSP stapling.
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 también tiene un período de validez finito, que a partir del 1 de septiembre de 2020 se establece en 13 meses. Sin embargo, durante ese período de validez, el propietario del certificado y/o la autoridad de certificación (CA) que emitió el certificado pueden declarar que ya no es de confianza. En estos desafortunados casos, los certificados no confiables deben ser revocados y los usuarios deben ser informados. Esto se hace añadiendo el certificado TLS/SSL no confiable a una Lista de Revocación de Certificados (CRL).
Aquí hay un ejemplo de una advertencia de certificado SSL/TLS revocado en Google Chrome (Fuente de la imagen)
¿Qué es una Lista de Revocación de Certificados (CRL)?
La revocación de certificados es un componente de importancia crítica 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 –esencialmente, todos los certificados que han sido revocados por la CA o el propietario y que ya no deberían ser de confianza.
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 marca de tiempo 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 RFC5280. 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.
Cómo los navegadores web y las aplicaciones verifican las CRL
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 TLS conexión 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 verifica si el certificado está incluido en la CRL emitida por la CA correspondiente. Según el estado del certificado del servidor, el navegador establecerá una conexión segura o alertará al usuario sobre el certificado revocado y el riesgo de continuar con una sesión no cifrada.
La verificación de las CRL es un paso esencial en una transacción basada en PKI porque verifican la identidad del propietario del sitio y determinan si el certificado asociado es de confianza.
A continuación, se presenta un flujo de trabajo ilustrado del proceso de verificación de revocación de certificados utilizando CRL
¿Qué es un punto de distribución de CRL (CDP)?
Cuando una aplicación o navegador verifica 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, generalmente se almacena en caché hasta que la propia CRL caduca. El CDP debe ser accesible en todo momento para garantizar que los dispositivos o las 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 verificaciones del estado de revocación del certificado fallarán.
¿Por qué son importantes las CRL?
Los certificados digitales se revocan por muchas razones y existen muchos ejemplos recientes de revocaciones masivas de certificados. Las razones para la revocación de certificados incluyen las siguientes:
- La CA descubre que ha emitido un certificado de forma indebida e incorrecta
- 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 tergiversa alguna información utilizada en el proceso, o el propietario del sitio web ha violado los términos de su acuerdo con la CA
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:
- Violaciones de datos personales o sensibles. Un atacante que realice un ataque de intermediario (man-in-the-middle) podría interceptar la información personal y sensible que el usuario introduce en un servidor web. Esta información podría incluir números de seguridad social, información de cuentas bancarias, números de tarjetas de crédito, datos médicos, etc.
- Robo de identidad y suplantación. Un actor malintencionado 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 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érdida financiera. Con la información bancaria, de tarjetas de crédito y credenciales robadas, el ciberdelincuente está a un paso de robar el dinero del usuario.
- Instalación de malware. Acceder a un sitio web inseguro es una forma en que los delincuentes instalan malware en el ordenador de la víctima. Este malware se utiliza luego para robar información personal, ejecutar keyloggers o secuestrar el ordenador para que forme parte de un ataque DDoS más grande. La instalación de malware también puede tener una motivación financiera, utilizando una variante de ransomware y cifrando todos los datos en el ordenador del usuario.
Consideraciones sobre el uso de CRL
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 dispositivosIoT .
Cuando una CA recibe una solicitud de CRL de un navegador, devuelve el archivo completo con los certificados revocados de esa CA. El navegador debe entonces analizar la lista para determinar si el certificado solicitado ha sido revocado o no. Dependiendo del tamaño del archivo, el proceso podría resultar en latencia y un rendimiento deficiente para los usuarios web.
Otro problema es que, si el cliente no dispone de una copia “adecuadamente reciente” de la CRL, debe obtener una durante la conexión inicial al sitio, lo que puede prolongar la duración de la conexión.
Lo cierto es que el mantenimiento de las CRL no es apropiado para la publicación y distribución de información crítica en tiempo casi real. Dado que los navegadores almacenan en caché las CRL para evitar la sobrecarga computacional, podría producirse una ventana de tiempo en la que un certificado revocado podría ser aceptado, creando riesgos de privacidad y seguridad para los usuarios.
OCSP y OCSP Stapling
Otro método utilizado para transmitir información a los usuarios sobre certificados revocados es el Protocolo de Estado de Certificado en Línea (OCSP). En lugar de descargar la última CRL y analizarla para verificar si un certificado solicitado está en la lista, el navegador solicita el estado de un certificado en particular al servidor de revocación de la CA emisora.
Utilizando el número de serie del certificado, el servicio OCSP verifica el estado del certificado, y luego la CA responde con una respuesta firmada digitalmente que contiene el estado del certificado. Una respuesta OCSP contiene uno de 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 presenta un flujo de trabajo ilustrado del proceso de verificación de revocación de certificados utilizando OCSP
OCSP stapling es una mejora del protocolo OCSP estándar y se define en RFC 6066. La habilitación de OCSP stapling 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 OCSP de la CA y, cuando el cliente inicia un handshake TLS, el servidor web “grapa” la respuesta OCSP al certificado que envía al navegador.
A continuación, se presenta un flujo de trabajo ilustrado del proceso de verificación de revocación de certificados utilizando OCSP Stapling
OCSP stapling presenta varias ventajas, entre ellas:
- Rendimiento mejorado, ya que el navegador recibe el estado del certificado del servidor cuando es necesario, evitando la sobrecarga de comunicarse con la CA emisora.
- Seguridad mejorada, al minimizar las instancias de falsos positivos y reducir el número de vectores de ataque.
- Privacidad del usuario mejorada, ya que las CA reciben solicitudes solo de sitios web y no de usuarios.
Por qué la monitorización de CRL y OCSP es fundamental
Si una CA está inoperativa, no podrá emitir nuevos certificados, pero si su CRL está caducada o inaccesible, todos sus certificados quedarán inmediatamente inutilizables. Como se ha comentado, la mayoría de las aplicaciones necesitan verificar la validez de los certificados contra un servidor CRL u OCSP. Si no pueden alcanzar el CDP o el respondedor OCSP, o si la propia CRL ha caducado, los usuarios no podrán acceder a su aplicación.
La monitorización de revocación en tiempo real y continua, proporcionada por herramientas de automatización del ciclo de vida de los certificados como Keyfactor Command, puede asegurar que esto no ocurra (ver video a continuación).
Todo se centra en una gestión eficiente del ciclo de vida de los certificados
La revocación eficaz y eficiente de certificados fraudulentos, comprometidos o no confiables refuerza la seguridad y la privacidad de millones de transacciones en línea cada día. Las organizaciones necesitan automatizar y gestionar centralmente sus certificados digitales para evitar costosas interrupciones o ataques debido a la revocación o caducidad de 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 de PKI y del ciclo de vida de los certificados.
