Explique en detalle cómo HTTPS garantiza la seguridad.

Introducción a Https

Que es Https

HTTPS (nombre completo: Hypertext Transfer Protocol over Secure Socket Layer) es un canal HTTP cuyo objetivo es la seguridad. En pocas palabras, es una versión segura de HTTP. Es decir, la capa SSL se agrega bajo HTTP, y la base de seguridad de HTTPS es SSL, por lo que se requiere SSL para los detalles del cifrado.

El papel de Https

• Cifrado de contenido Establecer un canal de seguridad de la información para garantizar la seguridad de la transmisión de datos;
• Verificación de identidad Confirma la autenticidad del sitio web
• Integridad de los datos para evitar que terceros suplanten o manipulen el contenido

Desventajas de Https

• El cifrado y descifrado de datos determina que es más lento que http

  Se requieren cifrado y descifrado asimétricos, y se requiere un protocolo de enlace de tres vías. La primera conexión es más lenta, por supuesto, ahora hay muchas optimizaciones.

Por razones de seguridad, el navegador no guardará el caché HTTPS localmente. De hecho, siempre que utilice comandos específicos en el encabezado HTTP, HTTPS se puede almacenar en caché. Firefox solo almacena HTTPS en la memoria de forma predeterminada. Sin embargo, siempre que haya Cache-Control: Public en el comando de encabezado, la caché se escribirá en el disco duro. IE puede almacenar en caché el contenido https siempre que el encabezado http lo permita, y la estrategia de almacenamiento en caché no tiene nada que ver con si se usa el protocolo HTTPS.

La diferencia entre HTTPS y HTTP

• El protocolo https requiere una CA para solicitar un certificado. Generalmente, hay pocos certificados gratuitos y se requiere una tarifa.
• http es un protocolo de transferencia de hipertexto y la información se transmite en texto plano; https es un protocolo de transferencia cifrado SSL seguro.
• HTTP y https usan métodos de conexión completamente diferentes y usan puertos diferentes. El primero es 80 y el segundo es 443.
• La conexión http es muy simple y sin estado; el protocolo HTTPS es un protocolo de red construido por el protocolo SSL + HTTP que se puede utilizar para la transmisión encriptada y la autenticación de identidad, que es más seguro que el protocolo http.

HTTP usa el puerto 80 por defecto, https usa el puerto 443 por defecto

La siguiente es la estructura completa de https. Ahora https básicamente usa TSL. Debido a que es más seguro, el SSL en la figura siguiente debe reemplazarse por SSL / TSL .

La siguiente es una introducción general a los puntos de conocimiento en la figura anterior.

Conocimientos relacionados con el cifrado y el descifrado

Cifrado simétrico

El cifrado simétrico (también llamado cifrado de clave privada) se refiere a un algoritmo de cifrado que utiliza la misma clave para cifrar y descifrar. A veces llamado algoritmo criptográfico tradicional, la clave de cifrado se puede calcular a partir de la clave de descifrado y la clave de descifrado también se puede calcular a partir de la clave de cifrado. En la mayoría de los algoritmos simétricos, la clave de cifrado y la clave de descifrado son iguales, por lo que este algoritmo de cifrado también se denomina algoritmo de clave secreta o algoritmo de clave única.
Cifrado simétrico común: DES (estándar de cifrado de datos), AES (estándar de cifrado avanzado), RC4, IDEA

Cifrado asimétrico

A diferencia del algoritmo de cifrado simétrico, el algoritmo de cifrado asimétrico requiere dos claves: clave pública y clave privada; y la clave de cifrado y la clave de descifrado aparecen en pares. Los algoritmos de cifrado asimétrico utilizan diferentes claves en el proceso de cifrado y descifrado. El cifrado asimétrico también se denomina cifrado de clave pública. En un par de claves, una de las claves está disponible públicamente para todos, llamada La clave pública, una de las cuales no es pública se denomina clave privada.

Los algoritmos de cifrado asimétrico tienen restricciones sobre la longitud del contenido cifrado, que no puede exceder la longitud de la clave pública. Por ejemplo, la longitud de la clave pública comúnmente utilizada es de 2048 bits, lo que significa que el contenido a cifrar no puede exceder los 256 bytes.

Algoritmo de resumen

El resumen digital utiliza una única función Hash para "digerir" el texto sin formato que debe cifrarse en una cadena de textos cifrados de longitud fija (128 bits). Esta cadena de textos cifrados también se denomina huella digital. Tiene una longitud fija y diferentes resúmenes de texto sin formato. Los resultados del texto cifrado son siempre diferentes y el resumen del mismo texto plano debe ser coherente. El "resumen digital" es la razón fundamental por la que https puede garantizar la integridad de los datos y la resistencia a la manipulación.

firma digital

La tecnología de firma digital es la aplicación de dos tecnologías: "cifrado y descifrado de clave asimétrica" ​​y "resumen digital", que cifra la información del resumen con la clave privada del remitente y la transmite al receptor junto con el texto original. El receptor solo puede usar la clave pública del remitente para descifrar la información de resumen cifrada y luego usar la función HASH para generar una información de resumen para el texto original recibido y compararla con la información de resumen descifrada. Si son iguales, significa que la información recibida está completa y no ha sido modificada durante la transmisión, en caso contrario significa que la información ha sido modificada, por lo que la firma digital puede verificar la integridad de la información.
El proceso de firma digital es el siguiente:
明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

La firma digital tiene dos funciones: en
primer lugar, puede confirmar que el remitente ha firmado y enviado el mensaje, porque otros no pueden falsificar la firma del remitente.
2. La firma digital puede confirmar la integridad del mensaje.

Nota: La
firma digital solo puede verificar la integridad de los datos. Si los datos en sí están encriptados no está bajo el control de la firma digital.

Certificado digital

¿Por qué existe un certificado digital?

Para la parte solicitante, ¿cómo puede estar seguro de que la clave pública que obtuvo debe haber sido emitida desde el host de destino y no ha sido alterada? ¿O el anfitrión de la solicitud está involucrado en actos indebidos de robo de información del usuario? En este momento, necesitamos tener una organización externa autorizada y confiable (generalmente una organización auditada y autorizada por el gobierno) para emitir uniformemente la clave pública de la organización anfitriona. Siempre que la organización solicitante obtenga la clave pública, lo mencionado anteriormente Ocurrió el problema.

Proceso de emisión de certificados digitales

El usuario primero genera su propio par de claves y transmite la clave pública y alguna información de identificación personal al centro de certificación. Luego de verificar la identidad, el centro de certificación realizará algunos pasos necesarios para asegurarse de que la solicitud sea efectivamente enviada por el usuario. Luego, el centro de certificación emitirá al usuario un certificado digital que contiene la información personal del usuario y su información de clave pública. Y también se adjunta la información de la firma del centro de certificación (firma de clave privada del certificado raíz). Los usuarios pueden utilizar sus propios certificados digitales para diversas actividades. Los certificados digitales son emitidos por agencias emisoras de certificados independientes y los certificados digitales son diferentes.Cada certificado puede proporcionar diferentes niveles de credibilidad.

Que contiene el certificado

• El nombre de la autoridad de certificación.
• Firma digital del propio certificado
• Clave pública del titular del certificado
• Algoritmo hash utilizado para la firma de certificados

Verificar la validez del certificado

El navegador utiliza de forma predeterminada un certificado raíz de CA integrado, donde el certificado raíz contiene la clave pública de la CA

1. La autoridad emisora ​​del certificado está falsificada: el navegador no la reconoce y piensa directamente que es un certificado peligroso.
2. La autoridad emisora ​​del certificado existe, por lo tanto, de acuerdo con el nombre de la CA, busque el certificado raíz de CA integrado correspondiente, la clave pública de CA. Utilice la clave pública de la CA para descifrar el resumen del certificado falsificado y descubra que no se puede resolver y se considera un certificado peligroso.
3. Para un certificado manipulado, use la clave pública de la CA para descifrar la firma digital para obtener el resumen A y luego calcule el resumen del certificado B de acuerdo con el algoritmo Hash firmado. Compare A y B. Si son iguales, es normal. Si no son iguales, está manipulado. Terminado.
4. Un certificado se puede revocar antes de que caduque, generalmente porque la clave privada del certificado se ha visto comprometida. Los navegadores más nuevos como Chrome, Firefox, Opera e Internet Explorer han implementado el Online Certificate Status Protocol (OCSP) para eliminar esta situación: el navegador envía el número de serie del certificado proporcionado por el sitio web a la autoridad de certificación a través de OCSP, este último Le dirá al navegador si el certificado aún es válido.

Los puntos 1 y 2 son para certificados falsificados. 3 es la verificación del certificado después de la manipulación y 4 es la verificación del certificado caducado.

SSL y TLS

SSL (capa de conexión segura, capa de conexión segura)

SSL es desarrollado por Netscape para garantizar la seguridad de la transmisión de datos en Internet. El uso de tecnología de cifrado de datos (Cifrado) puede garantizar que los datos no sean interceptados durante la transmisión en la red. La versión actual es 3.0.

El protocolo SSL se puede dividir en dos capas: Protocolo de registro SSL: se basa en un protocolo de transmisión confiable (como TCP) y proporciona funciones básicas como encapsulación, compresión y encriptación de datos para protocolos de alto nivel. Protocolo de protocolo de enlace SSL (Protocolo de enlace de SSL): se basa en el protocolo de registro SSL y se utiliza para autenticar la identidad de las partes que se comunican, negociar algoritmos de cifrado e intercambiar claves de cifrado antes de que comience la transmisión de datos real.

TLS (seguridad de la capa de transporte, protocolo de seguridad de la capa de transporte)

Se utiliza para proporcionar confidencialidad e integridad de datos entre dos aplicaciones.
TLS 1.0 es un nuevo protocolo formulado por IETF (Internet Engineering Task Force, Internet Engineering Task Force). Se basa en la especificación del protocolo SSL 3.0. Es la versión posterior de SSL 3.0 y puede entenderse como SSL 3.1. Está escrito Del RFC. El protocolo consta de dos capas: TLS Record y TLS Handshake. La capa inferior es el protocolo de registro TLS, ubicado sobre un protocolo de transporte confiable (como TCP).

Función del protocolo SSL / TLS:

• Autenticar usuarios y servidores para garantizar que los datos se envíen al cliente y servidor correctos;
• Cifre los datos para evitar que los roben en el medio;
• Mantenga la integridad de los datos y asegúrese de que no se modifiquen durante la transmisión.

Ventajas de TLS sobre SSL

1. Utilice el método de clave hash para la autenticación de mensajes: TLS utiliza el "método de clave hash del código de autenticación de mensajes" (HMAC), cuando el registro se transmite en una red abierta (como Internet), este código garantiza que el registro no se modificará. SSLv3.0 también proporciona autenticación de mensajes con clave, pero HMAC es más seguro que la función MAC (código de autenticación de mensajes) utilizada por SSLv3.0.
2. Función pseudoaleatoria mejorada (PRF): PRF genera datos clave. En TLS, HMAC define PRF. PRF utiliza dos algoritmos hash para garantizar su seguridad. Si se expone algún algoritmo, siempre que no se exponga el segundo algoritmo, los datos siguen estando seguros.
3. Verificación de mensajes completados mejorada: tanto TLS como SSLv3.0 proporcionan mensajes completos a los dos puntos finales, y el mensaje verifica que los mensajes intercambiados no se hayan modificado. Sin embargo, TLS basa este mensaje completo en los valores PRF y HMAC, que también es más seguro que SSLv3.0.
4. Manejo consistente de certificados: a diferencia de SSLv3.0, TLS intenta especificar los tipos de certificados que deben intercambiarse entre TLS.
5. Mensajes de alerta específicos: TLS proporciona alertas más específicas y adicionales para indicar problemas detectados por cualquier punto final de conversación. TLS también registra cuándo deben enviarse determinadas alertas.

Proceso de protocolo de enlace SSL, TLS

El proceso completo del protocolo de enlace SSL y TLS se muestra en la siguiente figura. El contenido específico de cada paso se describirá en detalle a continuación:

El cliente realiza la primera solicitud

Debido a que el cliente (como un navegador) tiene diferentes niveles de soporte para algunos algoritmos de cifrado y descifrado, se debe utilizar el mismo conjunto de algoritmos de cifrado y descifrado en el proceso de transmisión del protocolo TLS para garantizar que los datos se puedan cifrar y descifrar normalmente. En la fase de protocolo de enlace de TLS, el cliente primero debe informar al servidor qué algoritmos de cifrado admite, por lo que el cliente debe enviar una lista de conjuntos de cifrado compatibles localmente al servidor. Además, el cliente debe generar un número aleatorio. Este número aleatorio debe almacenarse en el lado del cliente y, por otro lado, debe transmitirse al servidor. El número aleatorio del cliente debe combinarse con el número aleatorio generado por el servidor para generar lo siguiente Master Secret del que hablar.

El cliente debe proporcionar la siguiente información:
-Versión de protocolo compatible, como TLS 1.0
-Un número aleatorio generado por el cliente, que luego se utiliza para generar una "clave de sesión"
-Métodos de cifrado compatibles, como cifrado de clave pública RSA
-Soportado Método de compresión

El servidor responde por primera vez

Una vez que el servidor recibe el saludo del cliente del cliente, el servidor debe determinar la versión del protocolo de cifrado y el algoritmo de cifrado, y luego también generar un número aleatorio y enviar su propio certificado al cliente y enviarlo al cliente. El número aleatorio aquí es el segundo número aleatorio en todo el proceso.

Información que el servidor debe proporcionar: -Versión del
protocolo
-Algoritmo de
cifrado
-Número aleatorio -Certificado del servidor

El cliente responde de nuevo

El cliente primero verifica el certificado emitido por el servidor. Después de pasar la verificación, las siguientes operaciones continuarán. El cliente genera un número aleatorio (el tercer número aleatorio) nuevamente y luego lo encripta con la clave pública en el certificado del servidor. Y coloque un mensaje ChangeCipherSpec, es decir, el mensaje con el cambio de codificación, así como el valor hash de todos los mensajes anteriores, realice la verificación del servidor y luego use la nueva clave para cifrar un dato y enviarlo al servidor para asegurarse de que no haya ningún error antes de la comunicación formal.
El cliente utiliza los dos números aleatorios anteriores y el nuevo número aleatorio recién generado, y utiliza el algoritmo de cifrado determinado con el servidor para generar un secreto de sesión.

ChangeCipherSpec
ChangeCipherSpec es un protocolo independiente, que se refleja en el paquete de datos como un byte de datos, que se utiliza para informar al servidor que el cliente ha cambiado al estado de la suite de cifrado negociada previamente (Suite de cifrado) y está listo para usar la suite de cifrado negociada previamente. La suite de cifrado cifra los datos y los transmite.

El servidor responde de nuevo

Después de recibir los datos cifrados del tercer número aleatorio del cliente, el servidor utiliza la clave privada para descifrar los datos cifrados, verificar los datos y generar la clave secreta de la misma manera que el cliente. Una vez que todo esté listo, se enviará un ChangeCipherSpec al cliente para informarle que ha cambiado al estado del conjunto de cifrado negociado y está listo para usar el conjunto de cifrado y el secreto de sesión para cifrar los datos. Después de eso, el servidor también utilizará el secreto de sesión para cifrar un mensaje de finalización y enviarlo al cliente para verificar el éxito del canal de cifrado y descifrado establecido a través del protocolo de enlace.

Comunicación entre cliente y servidor

Una vez determinada la clave secreta, el servidor y el cliente cifrarán el mensaje con la clave secreta acordada y se comunicarán. Básicamente, se completa todo el proceso de apretón de manos.

Vale la pena mencionar que: El
protocolo SSL usa encriptación asimétrica en la fase de negociación y usa encriptación simétrica en la fase de transmisión, lo que significa que los datos transmitidos a través de SSL están encriptados con una clave simétrica. Porque el cifrado asimétrico es lento y consume recursos. De hecho, cuando el cliente y el host establecen una conexión mediante el cifrado asimétrico, el cliente y el host ya han determinado el algoritmo de cifrado simétrico y la clave de cifrado simétrico clave que se utilizan en el proceso de transmisión. Debido a que este proceso en sí es seguro y confiable, es decir, La clave de cifrado simétrico no puede ser robada ni mal utilizada. Por lo tanto, se garantiza que el cifrado simétrico de los datos durante la transmisión también sea seguro y confiable, ya que además del cliente y el host, es imposible que un tercero pueda robar y descifrar el cifrado simétrico. ¡Llave! Si alguien escucha a escondidas la comunicación, puede conocer el método de cifrado elegido por ambas partes y dos de los tres números aleatorios. La seguridad de toda la llamada depende únicamente de si se puede descifrar el tercer número aleatorio (secreto de Premaster).

Otros suplementos

Para datos confidenciales muy importantes, el servidor también debe verificar al cliente para asegurarse de que los datos se transmitan a un cliente seguro y legítimo. El servidor puede enviar un mensaje de Solicitud de certificado al cliente, solicitando al cliente que envíe un certificado para verificar la legitimidad del cliente. Por ejemplo, las instituciones financieras a menudo solo permiten que los clientes autenticados se conecten a su propia red y proporcionarán a los clientes formales una llave USB, que contiene un certificado de cliente.

Los primeros dos bytes del secreto de PreMaster son el número de versión de TLS, que es un número de versión más importante que se utiliza para verificar los datos del protocolo de enlace, porque en la fase Client Hello, el cliente enviará una lista de conjuntos de cifrado y el SSL / TLS actualmente compatible El número de versión se le da al servidor y se transmite en texto sin cifrar. Si el paquete de datos de protocolo de enlace está descifrado, es probable que el atacante colude el paquete de datos y elija un paquete de cifrado menos seguro y una versión para el servidor. Los datos están descifrados. Por lo tanto, el servidor debe comparar el número de versión del PreMaster descifrado en el texto cifrado con el número de versión de la etapa anterior de Client Hello. Si el número de versión es menor, significa que ha sido manipulado y deja de enviar mensajes inmediatamente.

recuperación de sesión

Hay dos formas de restaurar la sesión original: una se llama ID de sesión y la otra se llama ticket de sesión.

ID de sesión

La idea de ID de sesión es muy simple, es decir, cada conversación tiene un número (ID de sesión). Si se interrumpe la conversación, la próxima vez que vuelva a conectarse, siempre que el cliente dé este número y el servidor tenga un registro de este número, ambas partes pueden reutilizar la "clave de sesión" existente sin tener que volver a generar una.

Actualmente, todos los navegadores admiten el ID de sesión, pero su desventaja es que el ID de sesión a menudo solo se guarda en un servidor. Por lo tanto, si la solicitud del cliente se envía a otro servidor, la conversación no se puede reanudar.

boleto de sesión

El cliente envía un ticket de sesión enviado por el servidor en la última conversación. Este ticket de sesión está encriptado y solo el servidor puede desencriptarlo, incluye la información principal de la conversación, como la clave de la conversación y el método de encriptación. Cuando el servidor recibe el ticket de sesión, no es necesario volver a generar la clave de sesión después del descifrado.

Actualmente solo es compatible con los navegadores Firefox y Chrome.

para resumir

https en realidad agrega SSL / TLS entre la capa TCP y la capa http para proteger la seguridad de la capa superior. Utiliza principalmente cifrado simétrico, cifrado asimétrico, certificados y otras tecnologías para cifrar datos entre el cliente y el servidor, y finalmente lograr Garantice la seguridad de toda la comunicación.