Introducción
HTTPS (a través de SSL /TLS) usos cifrado de clave pública para proteger las comunicaciones del navegador de ser leídas o modificadas en tránsito a través de Internet. Los servidores proporcionan a los navegadores visitantes una clave pública que se utiliza para establecer una conexión cifrada para todos los intercambios de datos posteriores.
Sin embargo, solo recibo un trabajando la clave pública por sí sola no garantiza que (y, por extensión, el servidor) sea propiedad del control remoto correcto sujeto (es decir, persona, empresa u organización). Man-in-the-middle Los atacantes pueden manipular redes para servir sus propias claves, comprometiendo así cualquier comunicación.
Los navegadores evitan esto al autenticando Servidores HTTPS que usan certificados, que son documentos digitales que se unen una clave pública para un sujeto individual. El enlace se afirma al tener un confiable autoridad de certificación (CA) como SSL.com verificar la identidad de los posibles propietarios de certificados, a través de verificaciones automáticas y manuales contra bases de datos calificadas
Esta relación de confianza significa que la seguridad del usuario web no es absoluta; más bien, requiere que los usuarios confíen en los navegadores y las CA para proteger su seguridad. Por lo tanto, creemos que a todos los usuarios les conviene tener un conocimiento básico de cómo funciona la validación de certificados.
Tenga en cuenta que el proceso de validación del certificado (descrito en detalle en el documento estándar RFC 5280) es bastante complicado. En este artículo intentaremos guiarlo por un camino (un navegador que valida el SSL de un host /TLS certificado) y navegar por los detalles complejos que no tienen importancia para la mayoría de los usuarios.
Certificados y el formato X.509
Los certificados son archivos digitales en todos los aspectos, lo que significa que deben seguir un formato de archivo para almacenar información (por ejemplo, firmas, claves, emisores, etc.). Mientras privado PKI las configuraciones pueden implementar cualquier formato para sus certificados, de confianza pública PKIs (es decir, aquellos en los que confían los navegadores) deben cumplir con RFC 5280, que requiere el uso de X.509 v3 formato.
X.509 v3 permite que los certificados incluyan datos adicionales, como restricciones de uso o información de políticas, como extensiones, con cada extensión siendo crítico or no crítico. Los navegadores pueden ignorar extensiones no críticas no válidas o no reconocidas, pero deben procesar y validar todas las críticas.
Rutas de certificación y procesamiento de rutas
Las CA usan una clave privada para firmar criptográficamente todos los certificados emitidos. Dichas firmas pueden probar irrevocablemente que un certificado fue emitido por una CA específica y que no se modificó después de su firma.
Las CA establecen la propiedad de su clave de firma manteniendo un certificado auto emitido (denominado raíz) para la clave pública correspondiente. Las CA tienen que observar procedimientos estrictamente controlados y auditados para crear, administrar y utilizar una raíz, y para minimizar la exposición, normalmente se utilizará una raíz para emitir intermedio Certificados. Estos intermediarios se pueden utilizar para emitir los certificados de sus clientes.
Los navegadores se envían con una lista integrada de raíces confiables. (Estas son raíces de CA que han pasado los estrictos criterios de inclusión del navegador). Para verificar un certificado, un navegador obtendrá una secuencia de certificados, cada uno de los cuales habrá firmado el siguiente certificado de la secuencia, conectando la raíz de la CA firmante con la del servidor. certificado.
Esta secuencia de certificados se llama ruta de certificación. La raíz del camino se llama ancla de confianza y el certificado del servidor se llama hoja or entidad final certificado.
Construcción de caminos
A menudo, los navegadores tienen que considerar varias rutas de certificación hasta que puedan encontrar una válida para un certificado determinado. Aunque una ruta puede contener certificados que se "encadenan" correctamente a un ancla conocida, la ruta en sí puede rechazarse debido a restricciones en la longitud de la ruta, el nombre de dominio, el uso de certificados o la política.
Construir y evaluar todas las rutas posibles es un proceso costoso que se realiza para cada nuevo certificado que encuentra un navegador. Los navegadores han implementado varias optimizaciones para minimizar el número de rutas de candidatos rechazadas, pero profundizar en dichos detalles está más allá del alcance de este artículo.
Validación de ruta
Una vez que se construye una ruta de certificación candidata, los navegadores la validan utilizando la información contenida en los certificados. Una ruta es válida si los navegadores pueden demostrar criptográficamente que, a partir de un certificado firmado directamente por un ancla de confianza, la clave privada correspondiente de cada certificado se utilizó para emitir la siguiente en la ruta, hasta el certificado hoja.
Algoritmo de validación de ruta de certificación
RFC 5280 describe un algoritmo estándar que los navegadores siguen para validar una ruta de certificación de certificados X.509.
Básicamente, los navegadores iteran a través de todos los certificados en la ruta comenzando con el ancla de confianza (es decir, el certificado raíz), validando la información básica y las extensiones críticas de cada certificado.
Si el procedimiento concluye con el último certificado en la ruta sin errores, entonces la ruta se acepta como válida. Si se producen errores, la ruta se marca como no válida.
Procesamiento básico de certificados
Independientemente de cualquier extensión, los navegadores siempre deben verificar la información básica del certificado, como la firma o el emisor. Las siguientes secciones muestran la secuencia de comprobaciones que realizan los navegadores.
1. El navegador verifica la integridad del certificado.
El firma en el certificado se puede verificar usando criptografía de clave pública normal. Si la firma no es válida, el certificado se considera modificado después de su emisión y, por lo tanto, se rechaza.
2. El navegador verifica la validez del certificado.
Un certificado periodo de validez es el intervalo de tiempo durante el cual la CA firmante garantiza que mantendrá información sobre su estado. Los navegadores rechazan cualquier certificado con un período de validez que finalice antes o después de la fecha y hora de la verificación de validación.
3. El navegador comprueba el estado de revocación del certificado.
Cuando se emite un certificado, se espera que esté en uso durante todo su período de validez. Por supuesto, varias circunstancias pueden hacer que un certificado deje de ser válido antes de que expire naturalmente.
Tales circunstancias pueden incluir que un sujeto cambie su nombre o un supuesto compromiso de su clave privada. En casos como este, una CA necesita revocar el certificado correspondiente, y los usuarios también depositan su confianza en una CA para notificar a los navegadores el estado de revocación de sus certificados.
RFC 5280 recomienda que las CA usen listas de revocación para este propósito.
Listas de revocación de certificados (CRL)
Las CA emiten periódicamente una lista de certificados revocados firmada y con sello de tiempo llamada lista de revocación de certificados (CRL). Las CRL se distribuyen en repositorios disponibles públicamente, y los navegadores pueden adquirir y consultar la CRL más reciente de la CA al validar un certificado.
Un defecto de este método es que la granularidad temporal de la revocación se limita al período de emisión de la CRL. Un navegador será notificado de una revocación solo después de que todas las CRL emitidas actualmente estén programadas para actualizarse. Dependiendo de la política de la CA firmante, esto puede llevar una hora, un día o incluso hasta una semana.
Protocolo de estado del certificado en línea (OCSP)
Existen otros métodos alternativos para adquirir información del estado de revocación, siendo el más popular el Protocolo de estado de certificado en línea (OCSP)
Descrito en el documento estándar RFC6960, OCSP permite que un navegador solicite el estado de revocación de un certificado específico desde un servidor OCSP en línea (también llamado respondedor) Cuando se configura correctamente, OCSP es mucho más inmediato y evita el problema de latencia de actualización de CRL mencionado anteriormente. Adicionalmente, Grapado OCSP Mejora el rendimiento y la velocidad.
4. El navegador verifica al emisor
Los certificados normalmente están asociados con dos entidades:
- El editor, que es la entidad propietaria de la clave de firma y
- El sujeto, que se refiere al propietario de la clave pública que autentica el certificado.
Los navegadores comprueban que un certificado editor el campo es el mismo que el sujeto campo del certificado anterior en la ruta. Para mayor seguridad, la mayoría PKI Las implementaciones también verifican que la clave del emisor sea la misma que la clave que firmó el certificado actual. (Tenga en cuenta que esto no es cierto para el ancla de confianza, ya que las raíces son autoemitidas, es decir, tienen el mismo emisor y sujeto).
Procesamiento de restricciones
El formato X.509 v3 permite a una CA definir restricciones o restricciones sobre cómo cada certificado se valida y utiliza como extensiones críticas. Cada certificado en la ruta puede imponer restricciones adicionales que todos los certificados posteriores deben obedecer.
Las restricciones de los certificados rara vez afectan al usuario medio de Internet, aunque son bastante comunes en las soluciones SSL empresariales. Las restricciones funcionales pueden servir para varios propósitos operativos, pero su uso más significativo es mitigar problemas de seguridad conocidos.
5. El navegador verifica las restricciones de nombre
Una CA intermedia de propiedad privada (pero de confianza pública) con el restricciones de nombre puede proporcionar a una organización un control detallado sobre la gestión y emisión de certificados. Los certificados se pueden limitar a un dominio o árbol de dominio específico (es decir, incluidos subdominios) para el nombre de dominio de una empresa u organización. Las restricciones de nombre se utilizan a menudo para certificados de CA intermedios comprados a una CA de confianza pública para evitar que la CA intermedia emita certificados perfectamente válidos para dominios de terceros (p. Ej. google.com).
6. El navegador verifica las restricciones de política
Una política de certificados es un documento legal publicado por una CA, que detalla oficialmente los procedimientos que siguen para emitir y administrar sus certificados. Las CA pueden emitir un certificado bajo una o más políticas, y los enlaces a estos se incluyen en cada certificado emitido para que las partes confiantes puedan evaluar estas políticas antes de decidir confiar en ese certificado.
Por razones legales y operativas, los certificados pueden imponer restricciones a las políticas a las que pueden estar sujetos. Si se encuentra que un certificado contiene restricciones de política críticas, los navegadores deben validarlo antes de continuar. (Sin embargo, las restricciones políticas críticas rara vez se encuentran en el mundo real y, por lo tanto, no se tendrán en cuenta para el resto de este artículo).
7. El navegador verifica las restricciones básicas (también conocido como longitud de la ruta)
El formato X.509 v3 permite a los emisores definir la longitud máxima de ruta que puede admitir un certificado. Esto proporciona control sobre hasta qué punto se puede colocar cada certificado en una ruta de certificación. Esto es realmente importante: los navegadores solían ignorar la longitud de la ruta de certificación hasta que un investigador demostró, en un 2009 presentation, cómo usó el certificado hoja de su sitio web para falsificar un certificado válido para un gran sitio web de comercio electrónico.
8. El navegador verifica el uso de la clave
La extensión "uso de clave" indica el propósito de la clave contenida en el certificado. Ejemplos de tales propósitos incluyen cifrado, firmas, firma de certificados, etc. Los navegadores rechazan los certificados que violan sus restricciones de uso de claves, como encontrar un certificado de servidor con una clave destinada únicamente a la firma de CRL.
9. El navegador continúa procesando todas las extensiones críticas restantes
Después de procesar las extensiones mencionadas anteriormente, los navegadores proceden a validar todas las extensiones restantes que el certificado actual designa como críticas, antes de pasar al siguiente. Si un navegador alcanza el certificado de hoja de una ruta sin errores, la ruta se acepta como válida. Si se produce algún error, la ruta se marca como no válida y no se establece una conexión segura.
Conclusión
La World Wide Web es un sistema complejo de partes móviles interconectadas y en constante evolución. La seguridad del navegador, por lo tanto, no es un problema resuelto, y esperamos que este artículo haya brindado una idea de la complejidad incluso del único componente que hemos analizado aquí. La confianza juega un papel importante para mantenerlo seguro en línea y, por esa razón, le instamos a que pregunte más sobre la política de certificados de su CA. (Siéntase libre de revisar Políticas de SSL.com aquí, de hecho.)
Gracias por elegir SSL.com, donde creemos que Safer Internet es un mejor Internet.
