Análisis del proceso de ejecución HTTPS
Usando una explicación de la wiki:
Protocolo de seguridad de transferencia de hipertexto (inglés: H yper T ext T ransfer P rotocol Secure, abreviatura: HTTPS; a menudo llamado HTTP sobre TLS, HTTP sobre SSL o HTTP Secure) es un protocolo de transporte para comunicaciones seguras a través de redes informáticas. HTTPS se comunica a través de HTTP pero utiliza SSL/TLS para cifrar los paquetes. El objetivo principal del desarrollo de HTTPS es proporcionar autenticación de identidad para el servidor del sitio web y proteger la privacidad y la integridad de los datos intercambiados. Este protocolo fue propuesto por primera vez por Netscape en 1994 y posteriormente se extendió a Internet.
Históricamente, las conexiones HTTPS se utilizaban a menudo para pagos de transacciones en la World Wide Web y la transmisión de información confidencial en sistemas de información empresarial. A finales de la década de 2000 y principios de la de 2010, HTTPS se utilizó ampliamente para garantizar la autenticidad de páginas web de todo tipo, proteger cuentas y mantener privadas las comunicaciones, las identidades y la navegación web de los usuarios.
Además, existe una implementación de transmisión segura HTTP del Protocolo seguro de transferencia de hipertexto (S-HTTP). Sin embargo, debido a la aplicación generalizada de HTTPS y a que se ha convertido en la implementación de transmisión segura HTTP de facto, S-. HTTP no se ha utilizado ampliamente.
ps: Después de leer la información, descubrí que el principio de S-HTTP es realizar cifrado asimétrico RSA para cada interacción de datos. En comparación con HTTPS, S-HTTP cifra la interacción de una sola transacción. HTTPS Es para cifrar la capa de comunicación. Creo que la eficiencia y la universalidad también pueden ser un factor importante para determinar si el mercado adoptará HTTPS en lugar de S-HTTP.
Transport Layer Security (inglés: Transport Layer Security, abreviatura: TLS) y su predecesor Secure Sockets Layer (inglés: Secure Sockets Layer, abreviatura: SSL) son un protocolo de seguridad El propósito del protocolo es proporcionar seguridad y protección de la integridad de los datos para las comunicaciones por Internet. Cuando Netscape lanzó su primer navegador web, Netscape Navigator, en 1994, lanzó el protocolo HTTPS y lo cifró con SSL. Este es el origen de SSL. IETF estandarizó SSL y publicó el documento estándar TLS 1.0 (RFC 2246) en 1999. Posteriormente se anunciaron TLS 1.1 (RFC 4346, 2006), TLS 1.2 (RFC 5246, 2008) y TLS 1.3 (RFC 8446, 2018). Este protocolo es muy utilizado en aplicaciones como navegadores, correo electrónico, mensajería instantánea, VoIP, fax por Internet, etc. Muchos sitios web, como Google, Facebook, Wikipedia, etc., también utilizan este protocolo para crear conexiones seguras y enviar datos. Ahora se ha convertido en el estándar de la industria para comunicaciones seguras en Internet.
SSL incluye una capa de registro (Record Layer) y una capa de transporte. El protocolo de la capa de registro determina el formato de encapsulación de los datos de la capa de transporte. El protocolo de seguridad de la capa de transporte utiliza autenticación X.509 y luego utiliza algoritmos de cifrado asimétrico para autenticar a las partes que se comunican y luego intercambia claves simétricas como claves de sesión. Esta clave de conversación se utiliza para cifrar los datos intercambiados entre las dos partes que se comunican para garantizar la confidencialidad y confiabilidad de la comunicación entre las dos aplicaciones, de modo que los atacantes no escuchen la comunicación entre las aplicaciones del cliente y del servidor.
Es un archivo electrónico utilizado en infraestructura de clave pública para acreditar la identidad del propietario de la clave pública. Este archivo contiene información de clave pública, información de identidad del propietario (asunto) y la firma digital de la autoridad de certificación del certificado digital (emisor) en este archivo para garantizar que el contenido general de este archivo sea correcto. Con este archivo, el propietario puede identificarse ante el sistema informático o ante otros usuarios, de modo que la otra parte pueda ganarse su confianza y estar autorizada a acceder o utilizar determinados servicios informáticos sensibles.
Los sistemas informáticos u otros usuarios pueden verificar el contenido del certificado mediante ciertos procedimientos, incluido si el certificado ha caducado y si la firma digital es válida. Si confía en la organización emisora, puede confiar en la clave del certificado y cifrarla y poseerla. con la clave pública para una comunicación confiable.
En resumen, la autoridad de certificación utiliza su propia clave privada para firmar digitalmente la clave pública de la persona (u organización) que necesita ser certificada y genera un certificado. Es decir, la esencia del certificado es. para firmar digitalmente la clave pública.
Las personas forman una arquitectura de cadena de confianza al confiar en el certificado raíz de la autoridad de certificación de certificados digitales y su autenticación de clave pública que utiliza cifrado de clave pública para la emisión de firmas digitales, que se ha implementado en TLS y se implementa en HTTPS. En la World Wide Web, SMTPS y STARTTLS se utilizan ampliamente en el correo electrónico. El estándar actual en la industria es X.509[2] desarrollado por el Sector de Normalización de Telecomunicaciones de la Unión Internacional de Telecomunicaciones, y está detallado en el RFC 5280 emitido por el IETF.
X.509 es el estándar de formato para certificados de clave pública en criptografía. Los certificados X.509 se han utilizado en muchos protocolos de red, incluido TLS/SSL, y también se utilizan en muchos escenarios de aplicaciones no en línea, como los servicios de firma electrónica. El certificado X.509 contiene la clave pública, información de identidad (como el nombre del host de la red, el nombre de la organización o el nombre del individuo, etc.) e información de firma (puede ser la firma de la autoridad emisora del certificado, CA, o puede ser autoautorizada). firmado). Para un certificado firmado por una autoridad emisora de certificados confiable o que puede verificarse por otros medios, el propietario del certificado puede usar el certificado y la clave privada correspondiente para crear comunicaciones seguras y firmar documentos digitalmente.
Además de la función del certificado en sí, X.509 también viene con una lista de revocación de certificados y un algoritmo de verificación de la validez del certificado de la autoridad emisora del certificado que finalmente firmó el certificado hasta el punto final de confianza.
X.509 es un conjunto de estándares de certificados definidos por el departamento de estandarización del ITU-T en base a su anterior ASN.1.
Hash, generalmente traducido como hash, hash o transliterado como hash, consiste en transformar una entrada de cualquier longitud (también llamada preimagen de mapeo previo) en una salida de longitud fija a través de un algoritmo hash. La salida es el valor hash.
El algoritmo Hash también se llama algoritmo hash. Aunque el algoritmo Hash se llama algoritmo, en realidad es más como una idea. El algoritmo Hash no tiene una fórmula fija, siempre que el algoritmo se ajuste a la idea de hash, se le puede llamar algoritmo Hash.
Características: No se puede revertir el crack, se puede utilizar para verificar la unicidad.
Utilizando el método de cifrado de un criptosistema de clave única, se puede utilizar la misma clave tanto para el cifrado como para el descifrado. de información, este método de cifrado se llama cifrado simétrico
Común: AES DES 3DES Características: Alta eficiencia
Un par de claves, clave pública y clave privada, los datos cifrados. solo la clave pública se puede descifrar con la clave privada, y los datos cifrados con la clave privada solo se pueden descifrar con la clave pública. La seguridad del cifrado asimétrico está garantizada por la factorización de números enteros extremadamente grandes (la implementación matemática se basa en). coprime, funciones de Euler, teorema de Euler, inversa modular, sin explicación detallada), la wiki dice esto:
Común: RSA Características: baja eficiencia, consumo prolongado
Existen los siguientes Peligros ocultos en el uso de información interactiva http:
Personalmente, debido a la inseguridad de HTTP, existe una necesidad urgente de un protocolo seguro que lo complemente. HTTPS se basa en el protocolo HTTP y agrega una capa de transporte de seguridad. protocolo (TLS/SSL) es un protocolo estándar, y x.509 es una implementación de este protocolo estándar. Y x.509 utiliza algoritmos hash relacionados con el cifrado, algoritmos de cifrado simétricos y algoritmos de cifrado asimétricos. p>
1.ClienteHola primera solicitud https Se basa en http, es decir, en tcp, por lo que primero se debe establecer el protocolo de enlace de tres vías de tcp, en el que no entraré. A través del protocolo de enlace de la capa SSL, que es el mensaje ClientHello en la imagen, el cliente envía la última versión local de TLS, un conjunto de combinaciones de algoritmos y mucha otra información auxiliar, y genera un número aleatorio A. El contenido específico se puede ver en la siguiente figura:
Puede ver que el número aleatorio (Random) es una hora GMT UNIX más una cadena de bytes aleatorios, y hay 26 combinaciones de algoritmos (Cipher Suite). .
2. ServerHello Después de recibir esta información, el servidor compara su propia versión de TLS, selecciona la inferior como retorno, selecciona una combinación adecuada del conjunto de combinaciones de algoritmos y luego también genera un número aleatorio. B se empaqueta en ServerHello y se envía de vuelta al Cliente. El contenido es como se muestra en la figura:
Aquí se selecciona una combinación de algoritmos CipherSuite.
3.Certificado, ServerHelloDone Después de seleccionar la estrategia de comunicación, el servidor le informa al cliente la información de su certificado (Certificado) y notifica al cliente sobre la información de actualización de la clave secreta (ServerkeyExchange). y significa que todo lo que debía enviarse te ha sido enviado, y mi Hola terminó (ServerHelloDone).
4. Después de recibir la información de los pasos 2 y 3, el Cliente primero verifica si el certificado es legal, incluida su autoridad emisora, coincidencia de nombre de dominio, período limitado, etc. Este proceso específico no se explorará . Siempre y cuando solo conozcas los pasos.
5. Después de pasar la verificación del certificado, se genera un número aleatorio C1 y luego se usa la clave pública en el contenido del certificado para cifrarlo con el algoritmo de cifrado asimétrico seleccionado por el servidor, y el resultado es C2.
6. Genere una D a partir de los tres números aleatorios anteriores A, B y C1 mediante una función pseudoaleatoria. ¡Esta es la clave de cifrado que realmente utiliza http al final! ! ! .
7. D vuelve a utilizar la función pseudoaleatoria para generar un grupo de claves secretas, que incluye 6 claves secretas, suponiendo P1, P2, P3, P4, P5, P6.
8.ClientKeyExchange. Notifique al servidor la información relacionada con la clave secreta y envíe el C2 calculado en el paso 5 al servidor.
9. Después de que el cliente envía ClientKeyExchange, calcula el valor hash de todos los mensajes interactivos anteriores con el servidor, asumiendo que es client_hash1, y usa uno de los P1 obtenidos en el paso 7 para cifrar, y el resultado es e.
10. Después de recibir C2, el servidor utiliza la clave privada combinada con el algoritmo asimétrico para descifrar C2 y obtener C1.
11. El mismo servidor también genera D (¡¡¡la clave de cifrado final!!!) basada en A, B y C1 mediante una función pseudoaleatoria, y luego usa D para obtener la clave secreta del grupo ( P1-P6), debido a que los algoritmos involucrados aquí son los mismos, por lo que las claves secretas obtenidas también son las mismas.
12. El lado del Servidor calcula el valor hash de todos los mensajes interactivos anteriores con el lado del Cliente. Supongamos que es server_hash2. Es posible que haya notado que 11 y 12 son los mismos que los procesos 6, 7 y 9. en el lado del Cliente, excepto que falta el proceso de cifrado P1 en .
13. En este momento, el cliente enviará el mensaje ChangeCipherSpec y el mensaje EncryptedHandshakeMessage para notificar al servidor que continúe usando la estrategia de cifrado seleccionada para la comunicación y pasará la E en el paso 9 al servidor. (El orden de los pasos aquí es solo para una mejor comprensión. Las dos líneas en realidad procesan información de forma independiente, por lo que no se puede garantizar el orden)
14. En este momento, el Cliente calculará nuevamente el protocolo de enlace anterior. El valor hash del mensaje da como resultado client_hash2.
15. Después de que el servidor recibe E traído por el mensaje EncryptedHandshakeMessage, utiliza P1 en el paso 11 para descifrar E. Dado que el algoritmo de cifrado y P1 son los mismos, client_hash1 se restaura aquí y luego es igual que en el paso 11. Si la comparación server_hash2 en 12 es la misma, significa que la otra parte ha entendido correctamente los mensajes anteriores para negociar la clave secreta.
16. El servidor vuelve a codificar el mensaje anterior para obtener server_hash2, usa P2 para cifrar el resultado como F y luego lo pasa al cliente a través del mensaje ChangeCipherSpec-EncryptedHandshakeMessage.
17. Después de recibir el mensaje del Servidor, el Cliente descifra y restaura el server_hash2 basado en P2. Si es consistente con el client_hash2, se considera que el proceso de interacción anterior es correcto y comprendido por el. otra parte. En este punto, todo el proceso de protocolo de enlace ha finalizado y los datagramas http posteriores se cifrarán y transmitirán mediante la política de cifrado y la clave de cifrado D previamente determinadas.
Resumen: de hecho, al final descubrimos que la clave de cifrado final D no se transmitió directamente durante todo el proceso de protocolo de enlace, y se intercambiaron algunas estrategias de algoritmo y algunos parámetros para generar D, lo cual es relativamente más seguro. Si D se pasa directamente, el cliente completará este proceso. Si algo sale mal en el medio, el servidor confiará en el D pasado por el cliente sin ningún conocimiento y sin condiciones, y pueden surgir problemas. y se pasan los parámetros, y ambas partes* **Participan juntas, por lo que la seguridad y la precisión mejorarán enormemente. Publique una imagen de captura de paquetes de todo el proceso:
Principalmente para evitar ataques de reproducción (ataques de reproducción) se refieren al atacante que envía un paquete que el host de destino ha recibido para engañar al sistema. Se utiliza principalmente en el proceso de autenticación de identidad para destruir la exactitud de la autenticación.
Cuando el cliente del navegador accede al mismo servidor https, no es necesario realizar un protocolo de enlace TLS completo cada vez, porque el protocolo de enlace TLS completo implica autenticar la identidad del servidor (certificado digital) y requiere mucho Las operaciones de cifrado/descifrado no simétrico, además de la función pseudoaleatoria PRF, se utilizan para derivar la clave de sesión a través del algoritmo de cifrado asimétrico RSA. /DSA es muy costoso en recursos de CPU.
Para superar esta dificultad, el servidor mantiene una estructura indexada por el ID de sesión, que se utiliza para almacenar temporalmente la clave de sesión y compartirla con el navegador durante la fase de protocolo de enlace TLS.
Cuando el navegador se vuelve a conectar al servidor https, durante la fase de protocolo de enlace TLS, presenta su propio ID de sesión y el servidor obtiene el ID de sesión. Utilizándolo como índice, puede obtener la clave de sesión compartida. por el navegador, utilizando la clave de sesión para cifrar/descifrar directamente el tráfico del usuario.
Esto evita muchos cálculos de potencia y exponentes.
Por supuesto, si el servidor no encuentra el ID de la sesión, la negociación del parámetro de seguridad TLS entre las dos partes seguirá el proceso normal.
Utilice charles para capturar paquetes y analizar el uso del ID de sesión. Supongamos que hay una solicitud y el servidor permite el uso del ID de sesión, entonces habrá el siguiente proceso:
1. El cliente inicia una solicitud HTTPS al servidor
2. Charles intercepta la solicitud del cliente, finge ser un cliente y realiza una solicitud al servidor
3. El servidor devuelve el certificado CA del servidor al "cliente" (en realidad Charles)
4. Charles intercepta la respuesta del servidor y obtiene la clave pública del certificado del servidor, luego crea un certificado tú mismo, reemplaza el certificado del servidor y envíalo al cliente. (En este paso, Charles obtuvo la clave pública del certificado del servidor)
5. Después de que el cliente recibe el certificado del "servidor" (en realidad Charles), genera una clave simétrica utilizando la clave pública de Charles. Cifrar y enviar al "servidor" (Charles)
6. Charles intercepta la respuesta del cliente, descifra la clave simétrica con su propia clave privada y luego la cifra con la clave pública del certificado del servidor y la envía al servidor. (En este paso, Charles obtiene la clave simétrica
7. El servidor descifra la clave simétrica con su propia clave privada y envía una respuesta al "cliente" (Charles)
8 Charles intercepta la respuesta del servidor, la reemplaza con su propio certificado y la envía al cliente.
En este punto, Charles ha obtenido la clave pública del certificado del servidor y la clave simétrica negociada. entre el cliente y el servidor, y luego puede descifrarlo. O modificar el mensaje cifrado
(Punto central: Charles generó su propio conjunto de claves públicas, claves privadas y su propio certificado. Porque su propio certificado). No puede pasar la verificación, el cliente debe tomar la iniciativa. Después de que el cliente autoriza, Charles puede reemplazar completamente al cliente e interactuar con el servidor. La interacción con el servidor utiliza el cifrado de clave pública y la interacción con el cliente. El descifrado de la clave privada del propio Charles)