Explicación detallada del pasado, presente y principios de HTTPS

Enciclopedia HTTPS:

HTTP es un protocolo de transmisión de texto claro que los datos se pueden espiar y manipular fácilmente, y los atacantes pueden hacerse pasar por el cliente y el servidor. HTTPS puede resolver estos dos problemas. Problemas de seguridad. HTTS sigue siendo el protocolo HTTP, pero el protocolo TSL/SSL para cifrar datos se agrega entre HTTP y TCP. Muchos otros protocolos de capa de aplicación también utilizan protocolos TSL/SSL además de la capa de transporte para garantizar la seguridad, como FTPS e IMAPS.

Se utiliza la misma clave para cifrar y descifrar. Tanto el cifrado como el descifrado requieren la misma clave. Algoritmos de cifrado simétrico comunes: AES, DES, 3DES.

Se utilizan diferentes claves para el cifrado y el descifrado. La clave utilizada para el cifrado se denomina clave pública y la clave utilizada para el descifrado se denomina clave privada. El texto cifrado cifrado con la clave pública sólo se puede descifrar con la clave privada. La clave pública se puede liberar para su uso, pero la clave privada no se debe filtrar. Algoritmos de cifrado asimétrico comunes: RSA, algoritmo de mochila, ECC.

Las firmas digitales se utilizan para verificar si los datos han sido manipulados, es decir, si los datos son consistentes con los datos originales.

La firma digital incluye dos operaciones: firma y verificación. Las firmas digitales son de no repudio y, una vez que la firma se verifica correctamente, no se puede repudiar.

Las firmas digitales generalmente incluyen una clave privada que usted conoce y una clave pública. La diferencia con el cifrado tradicional es que la clave privada se usa al firmar y la clave pública se usa para verificar la firma.

En 1994, Netscape propuso el protocolo SSL y formuló la especificación original del protocolo SSL, a saber, SSL1.0. Sin embargo, debido a que SSL1.0 utiliza un algoritmo de cifrado débil y ha sido cuestionado por la comunidad criptográfica, SSL1.0 no se ha hecho público.

Después de SSL1.0, Netscape realizó importantes mejoras en la especificación del protocolo SLL y lanzó el protocolo SSL2.0 en 1995. Aunque SSL versión 2.0 se considera un protocolo bastante potente y robusto, todavía tiene algunas vulnerabilidades, por lo que no se utiliza mucho.

Debido a los problemas de seguridad de SSL2.0, Netscape se asoció con Paul Kocher de Harvard y otros para rediseñar el protocolo SSL y lo lanzó en 1996 como versión SSL3.0. Esta versión tiene mayores limitaciones de seguridad que la versión SSL2.0. Diferencia de la versión 2.0. El protocolo SSL 3.0 es ampliamente reconocido y respaldado en Internet.

Con el rápido desarrollo de Internet, la seguridad de la red se está volviendo cada vez más importante. La industria necesita urgentemente un protocolo de seguridad estándar, por lo que IETE adoptó el protocolo SSL y lo renombró TSL (Protocolo de seguridad de la capa de transporte). , el protocolo de capa de transporte seguro, y lanzó TSL1.0 en 1999.

Sin embargo, TSL1.0 no es muy diferente de SSL3.0 (el número de versión del protocolo interno de TLS 1.0 es en realidad 3.1 /). p>

Aunque TSL es una actualización de SSL, todavía hay confusión en algunos términos, por lo que todos suelen referirse a los dos en conjunto como el protocolo SSL/TLS.

TSL1.1 se lanzó en 2006. Corrige algunas lagunas.

TSL1.2 se lanzó en 2008. La versión 1.2 eliminó principalmente algunos conjuntos de cifrado antiguos e introdujo el modo de cifrado AEAD.

La versión 1.2 es actualmente la versión más utilizada.

TSL1.3 se lanzó en 2018. La versión 1.3 se propuso en 2014. Después de cuatro años de repetidas revisiones, no fue hasta el borrador 28 que se incorporó oficialmente al estándar en 2018.

En comparación con la versión 1.2, la versión 1.3 tiene grandes cambios, lo que no sólo mejora la seguridad sino que también mejora enormemente la velocidad de acceso. Los principales cambios son los siguientes:

Si desea garantizar la seguridad del canal de comunicación cuando se comunica en la red pública, actualmente solo cifrar los datos de comunicación puede evitar escuchas, suplantaciones y manipulaciones.

Evite las escuchas ilegales:

Una vez cifrados los datos, el texto cifrado se transmite. Incluso si el texto cifrado se escucha, no se puede obtener sin la clave de descifrado del contenido real.

Antisuplantación y manipulación:

Los datos de comunicación se cifran y transmiten. Si no existe una clave de cifrado, es imposible construir un paquete de datos legal y no se puede suplantar. o alterar los datos.

Cifrar datos de comunicación y luego transmitirlos puede resolver muchos problemas de seguridad, pero el punto más crítico para lograr el cifrado de comunicación es cómo negociar las claves utilizadas para el cifrado en ambas partes para garantizar que las claves no se filtren. . ¿Y alterar eso? El acuerdo clave es la mayor dificultad en HTTPS.

El cifrado simétrico se utiliza durante la comunicación y la clave de cifrado simétrico se devuelve directamente al cliente cuando el cliente la solicita.

Pero antes de que se establezca un canal seguro, cualquier transmisión todavía se realiza en texto claro. No hay seguridad en el uso de texto sin formato para enviar la clave, y la misma clave se utiliza para el cifrado simétrico, por lo que un tercero. está escuchando a escondidas. Después de obtener la clave, puede espiar y alterar los datos, o hacerse pasar por el cliente y el servidor. Por lo tanto, distribuir directamente las claves para el cifrado simétrico obviamente no funciona.

Para facilitar la explicación, aquí solo analizamos la situación en la que el cliente envía datos al servidor en una dirección. El servidor envía datos al cliente de manera similar.

El cifrado asimétrico se utiliza durante la comunicación y la clave pública se devuelve al cliente cuando el cliente la solicita.

Sin embargo, cuando se devuelve la clave pública, aún se transmite en texto claro, por lo que la clave pública aún se puede filtrar fácilmente después de que se filtra la clave pública, aunque el tercero no puede espiar sin la clave. Los datos pueden suplantar directamente al servidor, pero debido a la filtración de la clave pública, un tercero aún puede hacerse pasar por el cliente o realizar un ataque de "intermediario".

Por lo tanto, simplemente usar cifrado asimétrico no funcionará.

Ataque de 'hombre en el medio':

Siempre que no se filtre la clave utilizada en la comunicación, no es necesario utilizar cifrado asimétrico durante la comunicación. , el cifrado simétrico es más eficiente. Por lo tanto, el cifrado asimétrico se puede utilizar para negociar la clave de cifrado simétrica utilizada en la comunicación antes de que la comunicación comience oficialmente. Los pasos son los siguientes:

Aunque la combinación de cifrado simétrico y cifrado asimétrico puede permitirnos obtener dos. Ventajas, pero esto aún no puede evitar los ataques de intermediarios.

El algoritmo de acuerdo de claves DH no intercambia claves directamente, sino que intercambia parámetros utilizados para producir claves. El algoritmo DH se basa en la "incapacidad" actual de descomponer números grandes para garantizar que incluso si los parámetros son. filtrado, los terceros tampoco pueden derivar la clave de los parámetros.

Pasos de negociación de claves del algoritmo DH:

A través de los pasos anteriores, el cliente y el servidor negociaron las claves, y no se transmitió ninguna durante todo el proceso. Para evitar que se rompan, a y b suelen ser muy grandes, p es un número primo de al menos 300 dígitos y g es generalmente muy pequeño, normalmente 3 o 5.

Sin embargo, las deficiencias de El algoritmo DH también es obvio. DH no puede evitar la suplantación, aún estará sujeto a ataques de intermediario.

El certificado digital, también conocido como certificado de clave pública o certificado de identidad, se utiliza para emitir claves públicas y acreditar la identidad del propietario de la clave pública.

Los certificados son emitidos por organizaciones de terceros para verificar la legitimidad del proveedor de servicios. Cuando se utilizan, el proveedor de servicios entrega el certificado al cliente y el cliente verifica la legitimidad del certificado a través de un mecanismo específico. , confiando así en el proveedor el lado del servidor del certificado y la clave pública en el certificado.

Los certificados digitales existen en forma de archivos. Los archivos de certificado contienen información de clave pública, información de identidad del propietario (sujeto) y la firma digital del propio certificado digital por parte de la autoridad de certificación del certificado digital (emisor). El certificado La firma digital se utiliza para garantizar que el certificado no ha sido manipulado.

Generalmente, cuando solicitamos un certificado de la CA, no necesitamos proporcionar la clave pública y la clave privada. La CA nos asignará un par de claves, escribirá la clave pública en el certificado y. luego danos el certificado y la clave privada.

Los certificados tienen estándares unificados y su legalidad (si el certificado ha caducado, si la firma digital es válida, si la autoridad emisora ​​es confiable) se verifica de acuerdo con estándares mediante ciertos procedimientos, por ejemplo, el navegador. garantizará que el certificado HTTPS sea legal o no, la biblioteca openSSL en Linux proporciona una función de verificación de certificado.

Después de verificar el certificado, si el certificado es confiable, puede usar la clave pública del certificado para cifrar los datos y comunicarse con el propietario del certificado.

El certificado HTTPS contiene información relacionada con el nombre de dominio en el campo de extensión, por lo que al solicitar un certificado HTTPS, la CA verificará estrictamente si la organización o individuo solicitante realmente posee el nombre de dominio.

Autoridad de Certificación Digital (inglés: Certificate Authority, abreviado como CA). El estándar de certificados está abierto al público y cualquiera puede crear un certificado, pero no se confía en los certificados elaborados por uno mismo. Sólo se confía en los certificados emitidos por organizaciones de CA autorizadas.

El proceso de revisión e implementación de certificados de CA autorizados es estricto y complicado, por lo que el período de validez de los certificados raíz autorizados suele ser de décadas.

Solo el certificado raíz de una CA autorizada será compatible con los principales sistemas operativos y estará preinstalado en el sistema operativo.

Los certificados generalmente siguen el texto cifrado después de cifrar el contenido. Al verificar el certificado, utilice el certificado raíz de la CA para verificar el texto secreto y determinar si el certificado es legítimo.

La estructura autorizada utiliza el certificado raíz para emitir certificados de CA secundaria, y los certificados de CA secundaria pueden emitir certificados para otros servicios. Pero no todos los certificados pueden seguir emitiendo nuevos certificados. Los certificados utilizan extensiones de restricciones básicas para limitar la emisión de certificados. Cuando generalmente solicitamos extensiones de restricciones básicas de certificados, son falsas. Al observar las restricciones básicas del certificado raíz, puede ver que la Autoridad de certificación es "Sí".

El certificado raíz no emite directamente el certificado de servicio, siempre que se base en los dos puntos siguientes:

El certificado de nivel superior firma el certificado de nivel inferior, y el valor de la firma está incluido en el certificado. Utilice la clave pública en el certificado de nivel superior para verificar el valor de la firma del certificado de nivel inferior. La firma del certificado raíz la firma usted mismo y la clave pública para verificar la firma está incluida en el certificado raíz.

El servidor debe devolver la conexión del certificado completo, pero algunos no lo devuelven. Para los certificados que no tienen la conexión del certificado completa, el campo extendido Identificador de clave de CA (Identificador de clave de autoridad) en el certificado. ) registra el certificado anterior del certificado, obtiene el certificado intermedio de nivel superior a través de este campo y luego continúa buscando hacia arriba desde este campo del certificado intermedio hasta el certificado raíz.

Es mejor que el servidor devuelva el certificado de conexión, para evitar que el navegador lo busque por sí solo y solicite la velocidad del protocolo de enlace.

La cadena de certificados devuelta por el servidor no incluye el certificado raíz, que se almacena dentro del sistema operativo.

En Linux, la biblioteca openssl integrará el certificado raíz. Verifique la ruta de almacenamiento del certificado raíz de openssl a través de "openssl versión -a".

Al verificar el certificado, primero verifique la firma del certificado paso a paso de acuerdo con la cadena de certificados. La verificación de firma más crítica es el certificado raíz. El certificado raíz está preinstalado en el sistema operativo. Es muy difícil para la CA preinstalar su propio certificado en cada sistema, por lo que el certificado raíz en el sistema preinstalado es confiable.

Para revisar, al solicitar un certificado HTTPS, la CA realizará una verificación estricta para garantizar que el nombre de dominio pertenece a la organización que solicita el certificado. De esta manera, un atacante puede falsificar un certificado que cambie el nombre de dominio, pero el certificado raíz del certificado falsificado no existirá en el sistema, por lo que no se confiará en el certificado falsificado. De esta manera, la verificación de la cadena de certificados puede evitar eficazmente que el servidor sea "suplantado".

Después de la verificación de la firma digital del certificado anterior, solo verifica que el certificado sea efectivamente un certificado legal y luego también verifica la validez del certificado. La verificación de validez incluye principalmente los siguientes campos:

Verificación de legalidad Los certificados también pueden ser revocados por diversos motivos, como la filtración de la clave privada del certificado, la emisión del certificado por error, etc. Para verificar si el certificado es válido, se utiliza un mecanismo de revocación de certificado. se introduce.

OSCP es una interfaz de verificación de certificados proporcionada por el proveedor del certificado. Los usuarios pueden verificar si el certificado ha sido revocado llamando a la interfaz OSCP.

Sin embargo, el servicio OCSP puede ser inaccesible debido a fallas de la política o del servicio. En este caso, el navegador general optará por confiar en el certificado. Después de todo, solo hay unos pocos casos en los que se revoca el certificado. . Algunas CA también escriben la política después de una falla de OCSP en el campo de extensión del certificado y permiten que el usuario la maneje de acuerdo con el campo de extensión.

El método OSCP tiene sus propios defectos obvios. Al solicitar OSCP para verificar el certificado, también le dice a la CA cuándo y a qué servicios accedió. Qué debemos hacer si la CA utiliza nuestros datos de acceso. ¿Hacer el mal? Si la interfaz OCSP es muy lenta, ralentizará el Sudoku correspondiente de nuestro servicio. Para resolver estos dos problemas, los principales fabricantes de CA han lanzado conjuntamente la solución CRL.

La solución CRL consiste en extraer periódicamente la lista de certificados revocados a la máquina local, generalmente una vez cada pocos días. Al verificar el certificado, búsquelo en la lista local.

La CA escribirá la dirección actualizada de la CRL en el campo de extensión del certificado:

La CRL también tiene su propia determinación obvia. Primero, la CRL se extrae regularmente y no puede. Se garantiza que tendrá efecto en tiempo real. Entonces la lista CRL es generalmente muy grande y puede llegar a varios M.

CRLSet es una solución de creación propia para Chrome. Google considera que las actualizaciones de CRL son demasiado lentas. Cada CA tiene su propia CRL y hay demasiados contenidos de CRL. Así que hice un CRLSet yo mismo y agregué certificados de alto riesgo que fueron revocados por las principales CA al CRLSet. Chrome puede verificarlo en su propio CRLSet al verificar el certificado.

CRLSet solo contiene los certificados revocados por cada CA, que probablemente contiene 2 de todos los certificados revocados.

La actualización de CRLSet es relativamente rápida. Se actualizará desde cada CA en unas pocas horas como mínimo y se puede utilizar para que la revocación entre en vigor rápidamente cuando se requiere una revocación de certificado de emergencia.

CRLSet proporciona la herramienta /agl/crlset-tools para extraer y verificar si el certificado está en CRLSet.

Puede actualizar el CRLSet de Chrome en chrome://components/

El cliente envía una solicitud de saludo al servidor, que contiene la versión SSL/TSL del cliente, el paquete de cifrado compatible y un número aleatorio Aleatorio1

Después de que el servidor recibe el saludo del cliente, selecciona los conjuntos de cifrado y hash que se usarán más adelante en función de los conjuntos de cifrado admitidos por el cliente y los conjuntos de cifrado que admite y los devuelve a el cliente. y también se devuelve un número aleatorio Random2 producido por el servidor.

El servidor devuelve su propio certificado al cliente. Después de recibir el certificado, el cliente confía en el servidor verificando el certificado y lo obtiene. el certificado del certificado. Obtenga la clave pública en el certificado.

El servidor enviará inmediatamente la solicitud al cliente después de devolver el certificado. Sin embargo, esta solicitud no es necesaria. Los parámetros de interacción de la solicitud solo se enviarán si el conjunto de cifrado seleccionado requiere parámetros adicionales.

Si el algoritmo del proveedor del acuerdo de claves es un algoritmo DH, los parámetros DH se devuelven al cliente en la solicitud. Los algoritmos DH son los siguientes: DHE_DSS, DHE_RSA, ECDHE_ECDSAECDHE_RSA

. El algoritmo dh devolverá los parámetros p, g de dh, la clave pública de dh y la firma de la clave pública. La clave pública es g^b mod p, y b es el número aleatorio del servidor

Después de que el servidor envía la información anterior, enviará inmediatamente Server Hello Done para informar al cliente que se ha enviado la información relevante del servidor y esperará a que el cliente inicie la negociación de claves.

Tras recibir el mensaje, el cliente comienza a verificar el certificado, negociar la clave, etc.

Después de recibir el mensaje Server Hello Done del servidor, el cliente contará la clave maestra preliminar y la devolverá al servidor.

Si se utiliza el algoritmo RSA/ECDSA, se envía la clave maestra preparada.

Si se utiliza el algoritmo DH, entonces lo que se envía es la clave pública contada a través de los parámetros anteriores, es decir, B (g^b mod p Después de recibir B, el servidor pasa B^a). mod p Obtén el tercer número aleatorio. Y el cliente ha obtenido s hasta s = Ab mod.

En este punto, el servidor y el cliente han obtenido tres números aleatorios. Utilizando estos tres números aleatorios a través del algoritmo de cifrado previamente negociado, se obtiene una clave de cifrado simétrica, que será utilizada en comunicaciones posteriores. .

Esta solicitud se utiliza para notificar a la otra parte que la clave utilizada para la comunicación ha sido contada y todas las comunicaciones posteriores utilizarán esta clave. Tanto el servidor como el cliente emitirán esta solicitud; normalmente el servidor la emite primero.

Después de completar los pasos anteriores, ambas partes enviarán una solicitud Finalizada a la otra parte. Los datos Finalizados se cifran mediante la clave negociada para verificar si la clave negociada previamente y la versión del protocolo son válidas.

Materiales de referencia: