El mundo se está moviendo hacia TLS 1.3, ¡lo cual es muy bueno! Este artículo ofrece una descripción general de alto nivel de TLS 1.3, y una discusión sobre la efectividad de sus nuevas características.
Transport Layer Security
Seguridad de la capa de transporte, o TLS, es un protocolo criptográfico que protege los datos intercambiados a través de una red informática. TLS se ha hecho famoso como el S in HTTPS. Más específicamente, TLS se utiliza para proteger los datos del usuario web de los ataques a la red.
TLS fue diseñado como una alternativa más segura a su predecesor Secure Sockets Layer (SSL). A lo largo de los años, los investigadores de seguridad han descubierto un montón de vulnerabilidades que afectan a SSL, lo que motivó a IETF a diseñar TLS en un esfuerzo por mitigarlos.
Irónicamente, las versiones anteriores de TLS También se vieron afectados por vulnerabilidades peligrosas, que en última instancia condujeron a TLS 1.2 (es decir, la versión predeterminada recomendada por profesionales de la industria).
La mayoría de las vulnerabilidades de protocolo conocidas se mitigaron en TLS 1.2, pero este nivel de seguridad aún fue el resultado de una serie de parches en la parte superior de un diseño defectuoso.
Como respuesta, TLS 1.3 fue redactado desde cero en un esfuerzo por diseñar limpiamente un moderno y seguro TLS protocolo. Cinco años de pruebas más tarde, finalmente se aprobó y ahora está cerca de ser el estándar de seguridad de Internet predeterminado.
TLS las versiones y sus respectivos documentos RFC se pueden encontrar en la siguiente lista:
- TLS 1.0 fue publicado como RFC 2246 en 1996
- TLS 1.1 fue publicado como RFC 4346 en 2006
- TLS 1.2 fue publicado como RFC 5246 en 2008
- TLS 1.3 fue publicado como estándar propuesto en RFC 8446 en el 2018.
¿Cómo envejecer TLS versiones funcionan?
Para discutir efectivamente los beneficios de TLS 1.3, primero debemos hablar sobre la antigüedad TLS las versiones funcionan (y cómo no).
TLS es un camiones híbridos sistema criptográfico, lo que significa que usa ambos asimétrico (clave pública) y simétrico cifrado (basado en contraseña / frase). Esto es debido a criptografía asimétrica siendo órdenes de magnitud más lentos que sus equivalentes simétricos.
En consecuencia, TLS solo emplea claves públicas para que los clientes y servidores puedan intercambiar de forma segura una clave simétrica. Esta clave se puede utilizar para cifrar todas las comunicaciones posteriores, evitando la sobrecarga de rendimiento impuesta por el cifrado asimétrico.
TLS 1.2 admite múltiples algoritmos de intercambio de claves (por ejemplo, RSA, DH, etc.), junto con varios algoritmos (también conocidos como sistemas de cifrado) se utiliza para cifrar y descifrar mensajes. Esta gran cantidad de opciones alternativas requiere que los clientes y servidores negocien, para que todas las partes usen lo mismo TLS parámetros.
Esta negociación está estandarizada en un protocolo llamado apretón de manos. Si no está familiarizado con él, consulte este artículo para obtener más información.
Entonces, ¿qué pasa con TLS 1.2?
Aunque TLS Se ha demostrado que 1.2 funciona bien en la mayoría de los casos, existen preocupaciones sobre el nivel general de seguridad y privacidad que proporciona después de años de parches y revisiones.
Aparte de las consideraciones de seguridad, sin embargo, TLS 1.2 también impone un rendimiento innecesario y una sobrecarga de red.
TLS Problemas de seguridad de 1.2
Con los años, los investigadores (y los atacantes) han descubierto una serie de vulnerabilidades en muchos TLS 1.2 componentes, incluidos algoritmos de intercambio de claves, cifrados y firmas digitales. Algunos de estos fueron errores de implementación de los que quizás haya oído hablar, como heartbleed or Enloquecido. Sin embargo, algunas eran vulnerabilidades de protocolo, es decir, explotan malas decisiones de diseño en TLS versiones (es decir, antes TLS 1.2).
Aunque la mayoría de la implementación y otros errores se corrigieron en TLS 1.2, desafortunadamente las vulnerabilidades en el diseño del protocolo no se pueden remediar usando solo un parche de software. Como resultado, para hacer eso, IETF tuvo que rediseñar completamente el protocolo de protocolo de enlace en TLS 1.3.
Ha habido muchas preocupaciones sobre TLS seguridad, pero uno de los más impactantes fue la comprensión de que TLS 1.2 (y todas las versiones anteriores, incluido SSL) es vulnerable a ataques de degradación debido a una falla en el diseño de su protocolo de protocolo de enlace. Más específicamente, TLS 1.2 no utiliza firmas digitales para proteger la integridad del apretón de manos. Las firmas protegen parte del apretón de manos, solo después de la negociación del conjunto de cifrado.
Como consecuencia, los atacantes pueden manipular cualquier negociación de un conjunto de cifrado de terceros que se produzca en la misma red informática (por ejemplo, wifi del aeropuerto), y forzar el uso de un cifrado inseguro. Luego pueden romper esa cifra vulnerable y obtener acceso injustificado a toda la conversación.
TLS 1.2 problemas de rendimiento
Además de estas consideraciones de seguridad, TLS 1.2 de la necesidad de negociar numerosos TLS los parámetros pueden imponer una sobrecarga de rendimiento en HTTPS (u otro TLS protegido) comunicaciones.
TLS El protocolo de enlace de 1.2 pasos de 4 requiere dos intercambios de ida y vuelta, primero para seleccionar el conjunto de cifrado y luego para intercambiar los certificados y las claves simétricas (o claves compartidas).
Esto significa que por cada TLS conexión a establecer, dos transacciones adicionales con el servidor son obligatorios Como resultado, TLS las conexiones requieren más ancho de banda y potencia que HTTP (sin cifrar), lo que puede ser particularmente costoso para las aplicaciones de Internet de las cosas (IoT), donde la baja potencia y el consumo de ancho de banda son restricciones difíciles.
TLS 1.2 problemas de privacidad
Y por último, TLS 1.2 ha sido criticado por comprometer la privacidad del usuario web.
Más específicamente, TLS ofrece una extensión conocida como Indicación del nombre del servidor o SNI. SNI permite incluir el nombre de host de un servidor en el protocolo de enlace SSL inicial. Esta extensión se utiliza para alojamiento virtual, donde los servidores pueden servir a varios dominios en la misma dirección IP y puerto, al tiempo que presentan un certificado diferente para cada dominio.
In TLS 1.2, se envían SNI sin cifrar, a pesar del uso de HTTPS, un atacante de red puede filtrar esta información y rastrear las páginas web que visita un usuario.
¿Cómo TLS 1.3 arreglar todo eso?
TLS 1.2 (y versiones anteriores) se centraron en mantener la compatibilidad con versiones anteriores. Cada versión construida sobre las anteriores con revisiones menores que intentan eliminar las vulnerabilidades publicadas entre TLS versiones.
Lamentablemente, esto también significó que las malas decisiones de diseño del protocolo (por ejemplo, el apretón de manos sin protección) también se heredaron en las versiones más recientes.
TLS 1.3 abandona la compatibilidad con versiones anteriores en favor de un diseño de seguridad adecuado. Ha sido diseñado desde cero para proporcionar una funcionalidad similar (pero no compatible) a TLS 1.2, pero con un rendimiento significativamente mejorado, privacidad y seguridad.
TLS Seguridad 1.3
Un principio básico de TLS 1.3 es simplicidad. En la nueva versión, todos los algoritmos de intercambio de claves, excepto el Diffie-Hellman (DH) intercambio de claves, se eliminaron. TLS 1.3 también ha definido un conjunto de parámetros DH probados y comprobados, eliminando la necesidad de negociar parámetros con el servidor.
Además, TLS 1.3 ya no admite cifrados innecesarios o vulnerables, como el modo CBC y el cifrado RC4. Se sabe que estos cifrados son susceptibles a los ataques, pero aún se admiten en la mayoría TLS implementaciones para compatibilidad heredada. Afortunadamente, la reciente oleada de ataques de descenso de categoría afecta a principios TLS las versiones motivaron a IETF a eliminar por completo tales cifrados de TLS 1.3.
Además, TLS 1.3 requiere que los servidores firmen criptográficamente todo el protocolo de enlace, incluida la negociación de cifrado, que impide que los atacantes modifiquen los parámetros del protocolo de enlace. Esto significa que TLS 1.3 es arquitectónicamente impermeable a los ataques de degradación que afectaron anteriormente TLS versiones.
Finalmente, las firmas mismas también se mejoraron mediante la implementación de un nuevo estándar, llamado RSA-PSS. Las firmas RSA-PSS son inmunes a los ataques criptográficos que afectan los esquemas de firmas empleados anteriormente TLS versiones.
TLS Rendimiento 1.3
Además de la seguridad mejorada, el conjunto reducido de parámetros y el apretón de manos simplificado en TLS 1.3 también contribuye a mejorar el rendimiento general. Dado que solo hay un algoritmo de intercambio de claves (con parámetros integrados) y solo un puñado de cifrados compatibles, el ancho de banda absoluto requerido para configurar un TLS 1.3 canales es considerablemente menor que las versiones anteriores.
Además, TLS 1.3 ahora admite un nuevo protocolo de protocolo de enlace, llamado Modo 1-RTT. En 1-RTT, el cliente puede enviar recursos compartidos de clave DH en el primer mensaje de protocolo de enlace, porque puede estar bastante seguro de los parámetros que utilizará el servidor. En el raro caso de que el servidor no los admita, puede producir un error para que el cliente envíe una configuración diferente.
En lugar de negociar los parámetros primero y luego intercambiar claves o recursos compartidos de claves, TLS 1.3 permite a un cliente configurar un TLS canal con solo una transacción de ida y vuelta (en lugar de dos, como se hizo anteriormente). Esto puede tener un gran efecto acumulativo en el procesamiento, el poder y los recursos de red que se requieren para que un cliente se comunique con un servidor a través de TLS 1.3.
Sin embargo, las optimizaciones de rendimiento no se detienen aquí, con otra TLS 1.3 característica, llamada Modo de reanudación 0-RTT. Cuando un navegador visita un servidor por primera vez y completa con éxito un TLS Apretón de manos, tanto el cliente como el servidor pueden almacenar una clave de cifrado precompartida localmente.
Si el navegador vuelve a visitar el servidor, puede usar esta clave de reanudación para enviar datos cifrados de la aplicación en su primer mensaje al servidor. Esto tiene la misma latencia que HTTP sin cifrar, porque no se requieren apretones de manos iniciales.
Cabe señalar que ha habido cierta seguridad preocupaciones de estudiantes y facultad sobre el modo 0-RTT en el pasado.
TLS Privacidad de 1.3
Aprendiendo de errores pasados, TLS 1.3 ahora ofrece un extensión que cifra la información SNI. Cuando se usa correctamente, esta extensión evita que los atacantes filtren el nombre de dominio del servidor remoto, por lo que no tienen ningún método para rastrear el historial del usuario HTTPS. Esta función proporciona mayor privacidad a los usuarios de Internet que las versiones anteriores de TLS.
Conclusión
Aunque la TLS 1.2 ha servido honorablemente todos estos años, TLS 1.3 es probablemente más seguro y eficiente. TLS 1.3 ha sido ampliamente probado en implementaciones experimentales de navegador, y ahora está listo para reemplazar TLS 1.2 como el protocolo de seguridad de red de elección. Publicación TLS 1.3 es un gran paso hacia una Internet más rápida y segura para todos.
Gracias por elegir SSL.com, donde creemos que Safer Internet es un mejor Internet.
