Mejor análisis del protocolo TLS 1.3
Seguridad de la red, frente al entorno de red complejo y en constante cambio, ¿qué conocimientos relevantes sobre seguridad de la red necesitamos dominar? Hablemos de temas relacionados con la seguridad de la red: HTTPS, SSL, TLS, etc.
Seguridad de red - HTTPS
La piedra angular de la seguridad de la red (Parte 1) - cifrado
La piedra angular de la seguridad de la red (Parte 2) - integridad y autenticación
Problemas de confianza de clave pública: certificados digitales y CA
La confianza comienza con el protocolo de enlace: explicación detallada de las conexiones TLS
Características de TLS 1.3
Cómo optimizar las conexiones HTTPS: aún necesita mejoras
Ya en 2013, el IETF (Internet Engineering Task Force) publicó un informe sobre la obsolescencia de TLS 1.2. Ya en 2013, el IETF (Internet Engineering Task Force) no estaba satisfecho con el diseño obsoleto y los dos viajes de ida y vuelta de TLS 1.2, y comenzó a desarrollar una nueva versión de TLS. Eirc Rescorla propuso una lista de deseos de características para la nueva versión de. TLS en agosto de ese año. Después de repetidas discusiones, la propuesta finalmente se definió como TLS 1.3. Los principales problemas que impulsaron el diseño de TLS 1.3 probablemente fueron:
Finalmente, el 10 de agosto de 2018, después de cuatro años, se lanzó la versión final de TLS 1.3: RFC-8446. El nuevo protocolo hace que Internet sea más rápido y más seguro; a medida que la tasa de adopción de TLS 1.3 continúa aumentando, tendrá un impacto a largo plazo en Internet, por supuesto, también es imperativo integrar sin problemas TLS 1.3 en el entorno en línea; lo antes posible.
Pero TLS 1.2 existe desde hace 10 años (2008). Después de experimentar varias pruebas y tribulaciones, el lanzamiento y la implementación del nuevo protocolo seguramente traerán nuevos desafíos. Echemos un vistazo a cómo hace esto la nueva versión de TLS.
Debido a que TLS 1.1/1.2 y otros protocolos existen desde hace muchos años, muchas aplicaciones y middleware solo reconocen el antiguo formato del protocolo de registro, lo que hace que las actualizaciones sean muy difíciles e incluso inflexibles.
Implementabilidad
Formalmente, incluso los cambios menores en el protocolo TLS 1.3 son difíciles de implementar ya que estos agentes/software intermediarios (middleware) no realizan bien los nuevos cambios (por ejemplo, eliminarlos). Los mensajes redundantes de ChangeCipherSpec y la actualización del número de versión de 0x03 a 0x04) también pueden causar fallas de conexión en algunos dispositivos. Esta es una de las razones clave por las que TLS 1.3 tardó tanto desde el borrador hasta el lanzamiento final.
Para garantizar que estos "dispositivos heredados" ampliamente implementados pudieran seguir utilizándose, TLS 1.3 tuvo que verse comprometido por una compatibilidad "falsa", es decir, dejar el formato de registro existente sin cambios para que TLS 1.3 pareciera "
Extensiones
Entonces, ¿cómo se puede saber si es 1.2 o 1.3?
Hay un nuevo acuerdo de extensión, que es similar a una "cláusula suplementaria" , por Agrega una nueva funcionalidad al agregar una serie de "campos de extensión" al final del registro que las versiones anteriores de TLS podrían ignorar porque no los reconocen, logrando así "compatibilidad con versiones anteriores". > TLS 1.3 utiliza extensiones para implementar muchas funciones importantes, como "grupos admitidos", "compartir claves", "algoritmo de firma", "nombre de servidor", etc.
TLS 1.2 ha acumulado una gran cantidad de información valiosa experiencia en más de diez años de práctica y descubrió muchas lagunas y debilidades en los algoritmos de cifrado. Por lo tanto, uno de los objetivos de diseño de TLS 1.3 es corregir diseños anteriores eliminando errores de diseños potencialmente peligrosos. para solucionar estas inseguridades.
Por ejemplo:
Intercambio de claves fijo
Después de estas "pérdida de peso", los algoritmos de intercambio de claves en TLS 1.3 solo tienen ECDHE y DHE, y elípticos. El algoritmo de curva (ECC) se "dividió" en un solo algoritmo. El algoritmo ECC también se ha "reducido" a sólo cinco tipos, incluidos P-256 y x25519.
Primero, hablemos de las razones para desaprobar los algoritmos de intercambio de claves RSA y DH:
Dado que el cliente elegirá ECDHE en lugar de RSA para el intercambio de claves, ECDHE no tiene. secreto directo (Forward Secrecy): "Supongamos que alguien registra los datos cifrados durante mucho tiempo y luego obtiene la clave privada RSA del servidor en un momento posterior. Luego, el pirata informático puede usar la clave privada para descifrar todos los mensajes anteriores". luego calcula la clave de sesión para descifrar todo el texto cifrado. Esto es una interceptación hoy y un descifrado mañana".
El algoritmo ECDHE genera un par de claves públicas y privadas temporales para cada protocolo de enlace, y la clave de cifrado para cada comunicación es. Los pares de claves son todos diferentes, es decir, "una clave a la vez". Incluso si el hacker dedica mucho esfuerzo a descifrar la clave de sesión esta vez, solo esta comunicación será atacada, y los mensajes históricos anteriores no se verán afectados y seguirán estando seguros.
Como resultado, los servidores y clientes convencionales ya no usan RSA durante la fase de protocolo de enlace, sino que usan ECDHE, y TLS 1.3 desaprobó explícitamente RSA y DH en el protocolo para garantizar una "seguridad directa" de nivel estándar. .
Contraseñas fijas
El mecanismo de intercambio de claves no es la única parte del protocolo que ha causado vulnerabilidades de seguridad a lo largo de los años; la parte de clave simétrica también ha tenido su cuota de problemas.
De manera similar, los algoritmos utilizados para el cifrado simétrico se han "reducido" a los modos de agrupación AES, ChaCha20 y AEAD de GCM, CCM y Poly1305, y los algoritmos de resumen de SHA 256 y SHA 384. La combinación de muchos algoritmos y parámetros de cifrado da como resultado conjuntos de cifrado que son muy complejos y difíciles de elegir. En TLS 1.3, sólo quedan cinco cifrados, lo que hace que sea "más fácil" para los clientes y servidores elegir conjuntos de cifrado. Pero lo más importante es que, a lo largo de la larga historia de TLS, estos algoritmos han demostrado ser inseguros, lo que genera vulnerabilidades de seguridad.
Arreglando firmas digitales
Como aprendiste en la sección anterior, otra parte importante de TLS es la autenticación. En cada conexión, el servicio proporciona autenticación al cliente mediante un certificado digital con clave pública. En el modo de cifrado RSA, el servidor demuestra que es propietario de la clave privada descifrando la clave maestra previa y calculando la MAC en el registro de conversación. En el patrón Diffie-Hellman, el servidor utiliza una firma digital para demostrar la propiedad de una clave privada.
En TLS 1.2 y versiones anteriores, la firma del servidor cubría solo una parte del protocolo de enlace. La parte utilizada para negociar qué cifrado simétrico utilizar no está firmada por la clave privada. Esto ha dado lugar a muchas vulnerabilidades de alto perfil, como FREAK, LogJam y otras. En TLS 1.3, estos problemas se evitan porque el servidor firma todo el registro de protocolo de enlace.
HTTPS Al establecer una conexión, además del protocolo de enlace TCP, se debe realizar un protocolo de enlace TLS, que en TLS 1.2 requiere dos viajes de ida y vuelta de mensajes adicionales (2 - RTT), lo que puede resultar en decenas de milisegundos Incluso cientos de milisegundos de latencia, y en las redes móviles la latencia puede ser mucho mayor.
Modo 1-RTT
Con los conjuntos de cifrado enormemente simplificados, no hay necesidad de pasar por el complicado proceso de negociación del pasado; TLS 1.3 comprime el proceso de negociación "Hola" anterior; y elimina el mensaje "Intercambio de claves" y capturó el mensaje "Intercambio de claves".
TLS 1.3 comprime el proceso de negociación "Hola" anterior, elimina el mensaje "Intercambio de claves" y captura el mensaje "Intercambio de claves", al tiempo que acorta el tiempo del protocolo de enlace a "1-RTT", reduciendo así la eficiencia. se duplica.
A continuación se muestra un diagrama simplificado del proceso de protocolo de enlace de TLS 1.3; tenga en cuenta las diferencias con el TLS 1.2 descrito anteriormente.
Recuperación 0-RTT
Además del protocolo de enlace estándar "1-RTT" inspirado en el protocolo QUIC, el cliente puede enviar datos cifrados al servidor en el primer mensaje. No hay ningún costo de latencia adicional en comparación con HTTP no cifrado.
En TLS 1.2, había dos métodos para reanudar una conexión: ID de sesión y ticket de sesión, mientras que 1.3 fusionó estos dos métodos en un nuevo modo llamado recuperación PSK (clave precompartida).
Análisis de protocolo de enlace
Actualmente, los servidores web como Nginx son totalmente compatibles con TLS 1.3, pero requieren que el OpenSSL subyacente sea 1.1.1, por lo que para implementarlo es necesario actualizar OpenSSL. versión primero.
Al establecer una conexión TCP, el navegador primero envía "Cliente Hola".
Dado que los mensajes 1.3 están destinados a ser compatibles con 1.2, el número de versión inicial, los conjuntos de cifrado admitidos y la estructura nonce (nonce del cliente) son todos iguales (esta vez el nonce es de 32 bytes).
Tenga en cuenta que la extensión en "Hola cliente", "supported_versions" significa que es TLS 1.3. "supported_groups" representa las curvas admitidas y "key_share" representa los parámetros correspondientes a las curvas.
Es como la vieja regla de "intenta decirlo de una vez", o simplemente "hola". Tengo la información aquí y también proporcioné información que puede ser útil más adelante dependiendo de la actualización.
Después de que el servidor reciba "Hola cliente", también devolverá un mensaje "Hola servidor", aún brindando un número aleatorio (número aleatorio del servidor) y el conjunto de cifrado seleccionado.
A primera vista, la versión es idéntica a TLS 1.2, pero sus extensiones le siguen de cerca. Supported_versions confirma que se está utilizando TLS 1.3 y luego proporciona la curva y los parámetros de clave pública correspondientes en la extensión "key_share".
El servidor responde de la misma forma que antes, seleccionando la información proporcionada por el cliente y algunos parámetros adicionales del lado del servidor, y negociando el cifrado. Luego, ambas partes pueden usar DH para calcular "Pre-Master" y luego usar HKDF para generar el secreto maestro "Master Secret