Transport Layer Security

.

TLS consta de dos componentes principales, protocolo de enlace TLS y registro TLS. En el protocolo de enlace TLS se lleva a cabo un intercambio de claves seguro y una autenticación . TLS Record luego utiliza la clave simétrica negociada en el protocolo de enlace TLS para la transmisión segura de datos: los datos se cifran y se transmiten con una MAC protegida contra cambios.

Para el intercambio de claves , se utilizan diferentes algoritmos con diferentes garantías de seguridad en las versiones anteriores de TLS. La última versión TLS 1.3 solo utiliza el protocolo de intercambio de claves Diffie-Hellman (DHE o ECDHE). Aquí hay una nueva conexión para cada clave de sesión (clave de sesión) negociada. Dado que esto sucede sin el uso de una clave a largo plazo, TLS 1.3 logra un secreto directo perfecto .  

La Oficina Federal de Seguridad de la Información de Alemania recomienda las versiones 1.2 y 1.3 cuando se utiliza TLS. Se prefieren los conjuntos de cifrado con Perfect Forward Secrecy .

Desde enero de 2017, el navegador web Chrome ha marcado sitios web que recopilan información sin usar HTTPS como inseguros. Se espera que esto conduzca a un aumento significativo en el uso de HTTPS. En febrero de 2017, HTTPS se activó en el 2,57% de todos los dominios de Internet alemanes registrados, así como en el 3,70% de los dominios austriacos y el 9,71% de los dominios suizos. Una investigación de alrededor de 40.000 sitios web de pequeñas y medianas empresas en Baden-Württemberg realizada por el Comisionado Estatal de Protección de Datos y Libertad de Información en Baden-Württemberg ha demostrado que alrededor del 7% de los sitios web examinados se ofrecen a través de HTTPS. Para aquellos sitios web que se ofrecen a través de HTTPS, el soporte del lado del servidor para TLS 1.0 todavía está muy extendido (99%).

Sin autenticación basada en certificados, TLS es susceptible a ataques man-in-the-middle : si el man-in-the-middle está activo antes de que se entregue la clave, puede engañar a ambos lados de sus claves y así registrar todos los datos traficar en texto plano y manipularlo sin que nadie lo note Debido a la falta de confiabilidad de algunas autoridades de certificación, la seguridad de TLS ha sido cuestionada desde principios de 2010. Sin embargo, si desactiva las autoridades de certificación cuestionables en su propio navegador, este riesgo puede eliminarse en gran medida.

En conexión con un servidor virtual , por ejemplo con HTTP ( por ejemplo, con el servidor Apache HTTP a través del mecanismo VHost ), es fundamentalmente una desventaja que solo se puede usar un certificado por combinación de dirección IP y puerto , ya que los datos reales del usuario del protocolo anterior (y, por lo tanto, el nombre del VHost) aún no se transmitieron en el momento del protocolo de enlace de TLS. Este problema se corrigió con la extensión TLS Server Name Indication (SNI) en junio de 2003 por el RFC 3546 . El nombre del servidor requerido se envía cuando se establece la conexión. La extensión original se describió para TLS 1.0, debido a la compatibilidad de las versiones individuales de TLS entre sí, SNI también se implementó para TLS 1.1, versión 1.2 y 1.3 de acuerdo con la recomendación. La versión 1.3 también intenta encriptar el SNI para no permitir que las partes sean leídas para revelar información sobre el servidor de destino a pesar de la conexión encriptada. Sin embargo, esto debe ser compatible con el navegador, se debe almacenar una clave en el Sistema de nombres de dominio (DNS) y se debe utilizar un DNS cifrado.

En la red Tor , los certificados TLS son de particular importancia para las conexiones a Internet, ya que una conexión no cifrada mediante un ataque de intermediario por parte de la computadora que establece la conexión a Internet (denominado "nodo de salida") sería muy fácil. Sin embargo, dado que una conexión entre dos puntos finales en la red Tor está encriptada, la transmisión encriptada de datos dentro de la red puede considerarse de importancia secundaria, siempre que se confíe en el enrutamiento de las conexiones. La característica principal del cifrado TLS es la autenticidad del otro lado.

Además de HTTPS como una variante cifrada de HTTP , otros casos de uso conocidos de TLS son, por ejemplo:

• POP3S para POP3
• SMTPS para SMTP
• NNTPS para NNTP
• SIPS para SIP
• IMAPS para IMAP
• XMPPS para XMPP
• IRCS para IRC
• LDAPS para LDAP
• MBS / IP -TLS
• FTPS para FTP
• EAP -TLS
• TN3270 -TLS
• OpenVPN

Las conexiones a los sistemas de bases de datos también se pueden asegurar mediante TLS. Se comprueba la identidad del servidor o del cliente y se encripta toda la comunicación.

Versiones

TLS en la pila de protocolos TCP / IP

solicitud	HTTPS	IMAPS	POP3S	SMTPS	...
solicitud	TLS
transporte	TCP
Internet	IP ( IPv4 , IPv6 )
Acceso a la red	Ethernet			FDDI	...

versión	Año de publicación	Observaciones
Versión antigua; ya no es compatible: SSL 1.0	1994
Versión antigua; ya no es compatible: SSL 2.0	1995	No se permite su uso desde marzo de 2011.
Versión antigua; ya no es compatible: SSL 3.0	1996	No se permite su uso desde junio de 2015.
Versión antigua; ya no es compatible: TLS 1.0	1999	No se permite su uso desde marzo de 2021.
Versión antigua; ya no es compatible: TLS 1.1	2006	No se permite su uso desde marzo de 2021.
Versión antigua; todavía soportado: TLS 1.2	2008
Versión actual: TLS 1.3	2018	RFC 8446 , también contiene nuevos requisitos para TLS 1.2

Leyenda:	Versión antigua; ya no es compatible	Versión antigua; todavía apoyado	Versión actual	Versión preliminar actual	Versión futura

• En 1994, nueve meses después del primer lanzamiento de Mosaic , el primer navegador web popular , Netscape Communications completó la primera versión de SSL (1.0).
• Cinco meses después, se publicó la siguiente versión SSL 2.0 junto con una nueva edición de Netscape Navigator.
• A finales de 1995, Microsoft lanzó la primera versión de su navegador web Internet Explorer . Poco tiempo después, también se conoció la primera versión de su homólogo SSL, PCT 1.0 (Tecnología de comunicación privada). PCT tenía varias ventajas sobre SSL 2.0 que luego se incorporaron a SSL 3.0.
• En el verano de 1996, Netscape entregó el control de versiones de su protocolo SSL 3.0 al IETF para desarrollar un estándar de Internet.
• A partir de noviembre de 1996, el IETF TLS WG desarrolló el "Protocolo de seguridad de la capa de transporte (TLS) Versión 1.0" (versión interna número 3.1) basado en SSL 3.0 de Netscape, que finalmente se publicó en enero de 1999 como RFC 2246 . El documento de especificación final para SSL 3.0 de Netscape fue difícil de encontrar durante muchos años y posteriormente se publicó como RFC 6101 en agosto de 2011 .
• Posteriormente, TLS se amplió con más RFC :
  • RFC 2712 - Adición de conjuntos de cifrado Kerberos a Transport Layer Security (TLS).
  • RFC 2817 - Actualización a TLS dentro de HTTP / 1.1 explica el uso del mecanismo de actualización en HTTP / 1.1 para inicializar Transport Layer Security (TLS) a través de una conexión TCP existente . Esto hace posible utilizar los mismos puertos TCP "conocidos" (80 y 443) tanto para el tráfico HTTP inseguro como seguro.
  • RFC 2818 - HTTP Over TLS separa el tráfico seguro del no seguro a través de puertos TCP de servidor separados.
  • RFC 3268 - Advanced Encryption Standard (AES) Ciphersuites para Transport Layer Security (TLS) utiliza la extensibilidad de TLS y agrega los algoritmos de cifrado simétrico ( RC2 , RC4 , International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES) y Triple DES ) el Estándar de cifrado avanzado (AES).
  • RFC 3546 - Extensiones de seguridad de la capa de transporte (TLS) introduce el concepto de extensiones, mediante el cual los campos de datos o encabezados opcionales se pueden transmitir, especialmente durante la negociación inicial. Una de estas extensiones es Indicación de nombre de servidor .
• En abril de 2006, la versión 1.1 de TLS se estandarizó en RFC 4346, haciendo obsoleto el RFC 2246 . En TLS 1.1, se han realizado pequeñas mejoras de seguridad y se han eliminado las ambigüedades.
• En agosto de 2008, apareció la versión 1.2 de TLS con RFC 5246 , lo que hizo obsoleto el RFC 4346 . La definición de MD5 / SHA-1 en la función pseudoaleatoria (PRF) y elementos firmados ha sido reemplazada por soluciones más flexibles en las que se pueden especificar los algoritmos hash.
• En agosto de 2018, se publicó la versión 1.3 de TLS en RFC 8446 , que se ha desarrollado desde 2014.
• En octubre de 2018, los fabricantes de los navegadores Firefox, Chrome, Edge y Safari declararon que ya no admitirían los protocolos TLS 1.0 y 1.1 obsoletos a partir de marzo de 2020. En Google Chrome 84, se ha eliminado la compatibilidad con TLS 1.0 y 1.1.

.

Protocolos TLS en la pila de protocolos

). TLS funciona de forma transparente, por lo que se puede utilizar fácilmente para hacer que las conexiones seguras estén disponibles para los protocolos sin sus propios mecanismos de seguridad. También se puede ampliar para garantizar la flexibilidad y la seguridad futura de las técnicas de cifrado utilizadas.

El protocolo TLS consta de dos capas:

Protocolo de protocolo de enlace TLS	Especificación de cifrado de cambio de TLS. Protocolo	Protocolo de alerta TLS	Protocolo de datos de aplicación TLS
Protocolo de registro TLS

Protocolo de registro TLS

El protocolo de registro TLS es la más baja de las dos capas y se utiliza para asegurar la conexión. Se basa directamente en la capa de transporte y ofrece dos servicios diferentes que se pueden utilizar de forma individual o conjunta:

Además, los datos a respaldar se fragmentan en bloques de un máximo de 16 384 (2 ¹⁴ ) bytes y se vuelven a ensamblar en el destinatario. El estándar estipula que el tamaño del bloque no excede este valor, a menos que el bloque esté comprimido o encriptado, entonces el tamaño del bloque puede ser de 1024 bytes (con compresión) o 2048 bytes (con encriptación) más grande. Los datos también se pueden comprimir antes del cifrado y antes del cálculo de la suma de comprobación criptográfica. El procedimiento de compresión, como la clave criptográfica, se negocia mediante el protocolo de enlace TLS.

La estructura de un mensaje de registro TLS es la siguiente: Tipo de contenido (1 byte: Cambiar especificación de cifrado = 20, Alerta = 21, Apretón de manos = 22, Datos de aplicación = 23) | Versión principal del protocolo (1 byte) | Versión de protocolo menor (1 byte) | Longitud (1 corto o dos bytes)

Protocolo de protocolo de enlace TLS

El protocolo TLS Handshake se basa en el protocolo de registro TLS y cumple las siguientes funciones incluso antes de que se hayan intercambiado los primeros bits del flujo de datos de la aplicación:

• Negociar algoritmos criptográficos y claves a utilizar. TLS también admite la transmisión no cifrada.
• Identificación y autenticación de los interlocutores en la comunicación sobre la base de métodos de cifrado asimétrico y criptografía de clave pública . Este paso es opcionalmente una autenticación bidireccional (en este caso, a veces se usa TLS mutua ), pero generalmente solo el servidor se autentica ante el cliente .

El apretón de manos en sí se puede dividir en cuatro fases :

1. El cliente envía un saludo de cliente al servidor y el servidor responde al cliente con un saludo de servidor . Los parámetros de los mensajes son:
   • la versión (la versión de protocolo TLS más alta admitida por el cliente)
   • una información aleatoria de 32 bytes de longitud (marca de tiempo de 4 bytes + número aleatorio de 28 bytes de longitud), que luego se utiliza para crear el secreto anterior al maestro (protege contra ataques de repetición )
   • un ID de sesión
   • el conjunto de cifrado que se utilizará (algoritmos para intercambio de claves, cifrado y autenticación)
   • Opcionalmente, el FQDN deseado para el soporte de indicación de nombre de servidor
   • En la versión TLS 1.3 (con intercambio de claves Diffie-Hellman ), las claves compartidas que definen la clave común también se transfieren aquí.

Protocolo de especificación de cifrado de cambio de TLS

El Protocolo de especificación de cambio de cifrado solo consta de un único mensaje. Este mensaje tiene un tamaño de un byte y tiene el contenido 1. Con este mensaje, el remitente informa al destinatario que está cambiando al conjunto de cifrado negociado en el protocolo de reconocimiento en la sesión activa . Una de las principales razones para definir un protocolo separado para este mensaje es que las implementaciones de TLS pueden combinar varios mensajes de un protocolo en un registro (es decir, una unidad de datos TLS). Esto no es deseable para el mensaje "Cambiar especificación de cifrado". Debido a que los registros de diferentes protocolos no se pueden combinar, el problema se resuelve definiendo un protocolo separado.

Protocolo de alerta TLS

El Protocolo de alerta distingue alrededor de dos docenas de mensajes diferentes. Uno de ellos anuncia el final de la sesión (close_notify). Otros se refieren, por ejemplo, a la sintaxis del protocolo o la validez de los certificados utilizados. Se hace una distinción entre advertencias y errores, y estos últimos terminan la conexión inmediatamente.

La estructura de un mensaje de error es la siguiente: AlertLevel (1 byte: Advertencia = 1, Fatal = 2) | AlertDescription (1 byte: close_notify = 0, […], no_renegotiation = 100).

Los siguientes tipos de errores graves se definen en la especificación de TLS:

mensaje_ inesperado	Se recibió un mensaje inapropiado.
bad_record_mac	Se recibió una MAC incorrecta .
descompresión_falla	El algoritmo de descompresión recibió datos incorrectos.
handshake_failure	El remitente no pudo editar un conjunto aceptable de parámetros de seguridad.
parámetro_inlegal	Un campo en el mensaje de protocolo de enlace estaba fuera de rango o estaba en conflicto con otros campos.

Las siguientes advertencias se definen en la especificación de TLS:

close_notify	Notifica a los destinatarios que el remitente no enviará más mensajes en esta conexión. Debe ser enviado como último mensaje por cada socio en una conexión.
no_certificate	Puede enviarse en respuesta a una solicitud de certificado si el certificado correspondiente no está disponible. (Eliminado en TLS 1.0)
bad_certificate	El certificado recibido estaba incompleto o era incorrecto.
unsupported_certificate	El tipo de certificado de recepción no es compatible.
certificado_revocado	El firmante retiró el certificado.
certificado_expirado	El certificado ha caducado.
certificate_unknown	Ocurrieron otras razones no especificadas mientras se editaba el certificado que dieron como resultado que el certificado se marcara como no válido.

Se han agregado las siguientes advertencias a la especificación de TLS 1.0:

decryption_failed	Falló el descifrado.
record_overflow
unknown_ca	CA desconocida o no confiable.
acceso denegado	Acceso denegado.
decode_error	Error de decodificación.
decrypt_error	Fallo de descifrado.
export_restriction	Restricción de exportación.
versión_protocolo	Versión obsoleta de TLS / SSL.
insuficiente_seguridad	Seguridad insuficiente.
error interno	Error interno.
user_canceled	Cancelación por usuario.
no_negociación

Protocolo de datos de aplicación TLS

Los datos de la aplicación se transportan a través del Protocolo de registro, desglosados ​​en partes, comprimidos y, según el estado actual de la sesión, también cifrados. En términos de contenido, TLS no los interpreta con más detalle.

Cálculo del secreto maestro

aún esté protegido en caso de que se considere que una de las funciones se ha visto comprometida. En TLS 1.2, este enfoque se reemplaza por la intercambiabilidad flexible de la función.

Se sabe que varios ataques socavan las garantías de seguridad en SSL y TLS. La siguiente lista representa parte de los ataques conocidos.

Relleno de ataques de Oracle

El criptólogo Serge Vaudenay descubrió en 2002 que un atacante intermediario puede obtener información del relleno de un mensaje cifrado con el modo de encadenamiento de bloques de cifrado (CBC) que se puede utilizar para descifrar el mensaje. Mediante la manipulación dirigida de un mensaje cifrado, el atacante se entera de si el servidor está informando un relleno válido y, por lo tanto, parte del texto sin formato se ha adivinado correctamente.

En octubre de 2014, los investigadores de seguridad demostraron el ataque POODLE ( Padding Oracle On Downgraded Legacy Encryption ), con el que un atacante fuerza una versión degradada de una conexión TLS para llevar a cabo un ataque Padding Oracle contra SSL 3.0. Por razones de compatibilidad, los navegadores web y otras implementaciones seguían admitiendo SSL 3.0, a pesar de las debilidades de seguridad conocidas en ese momento. Posteriormente, el Grupo de trabajo de ingeniería de Internet marcó SSL 3.0 como desactualizado y especificó un método para protegerse contra ataques de degradación en TLS.

BESTIA

SSL 3.0 y TLS 1.0 utilizan un vector de inicialización predecible en modo CBC. Un atacante puede utilizar un ataque de texto sin formato elegido para determinar partes desconocidas del texto sin formato. Un escenario de ataque es el robo de cookies HTTP , que se transmiten de forma cifrada. Para hacer esto, el atacante debe atraer a la víctima del ataque a un sitio web malicioso, que desencadena repetidamente solicitudes HTTP a un dominio extranjero, y el navegador web envía automáticamente las cookies HTTP configuradas para el dominio. El atacante puede adivinar la cookie carácter a carácter debido al contenido parcialmente autoseleccionado de las solicitudes HTTP y al escuchar los mensajes TLS cifrados.

Los conceptos básicos del ataque se describieron en 2004 y se demostraron en la práctica por primera vez en 2011 con el nombre BEAST ( Exploit del navegador contra SSL / TLS ). TLS versión 1.1 y superior no se ven afectados ya que cada mensaje está encriptado con un vector de inicialización pseudoaleatorio.

La diferencia criptográfica entre TLS 1.0 y TLS 1.1 es marginal y hay una solución trivial y compatible hacia abajo utilizando la división de registros TLS 1 / (n-1), lo que hace que esta diferencia marginal entre TLS 1.0 y TLS 1.1 sea formalmente demostrable irrelevante. Esta solución trivial fue implementada por todas las aplicaciones afectadas por BEAST en el transcurso de 2011. BEAST solo afecta a los navegadores web, Java en el navegador y SSL VPN, porque BEAST solo es posible como un ataque interno.

Ataques de compresión

: el atacante lleva a cabo un ataque de texto sin formato elegido y observa los mensajes TLS cifrados en la red. El proceso de compresión elimina las redundancias de los datos del usuario para que el texto sin formato a cifrar y, por lo tanto, también el texto cifrado se vuelva más corto. Si el atacante ha adivinado parte del texto sin formato desconocido, por ejemplo, un carácter de una cookie HTTP, lo aprende de la diferencia de longitud de un mensaje TLS cifrado.

El ataque fue publicado en 2012 por los creadores del ataque BEAST bajo el nombre CRIME ( Compression Ratio Info-leaking Made Easy ). Además de SSL y TLS, el protocolo SPDY también se ve afectado. No se recomienda el uso de compresión como medida de protección. TLS versión 1.3 o superior ya no admite la compresión. El sucesor de SPDY HTTP / 2 usa un formato de compresión simplificado ( HPACK ), que comprime de manera menos eficiente que Deflate , pero es más difícil de atacar.

. Dado que TLS no puede prevenir fundamentalmente los ataques de compresión, se deben usar medidas de protección específicas de la aplicación, por ejemplo, no usar compresión en absoluto.

Cambiar para exportar cifrado

y que solo usan claves cortas. A pesar de las debilidades de seguridad conocidas, algunas de ellas fueron o aún son compatibles con implementaciones. El protocolo de enlace de TLS está destinado a evitar que un atacante intermediario fuerce una degradación a un conjunto de cifrado no solicitado mediante la autenticación de los mensajes de protocolo de enlace. Sin embargo, la seguridad de la autenticación también depende del paquete de cifrado negociado, por lo que el atacante puede romper la clave.

Poco después, un equipo de investigadores publicó el ataque Logjam, que permite degradar el intercambio de claves Diffie-Hellman a grupos de clases residuales de 512 bits. La razón de esto es el soporte de conjuntos de cifrado exportables con Diffie-Hellman efímero. A diferencia de FREAK, hay una debilidad en el protocolo en TLS, que también se puede explotar sin errores de implementación. El ataque Logjam se puede realizar con alto rendimiento en la práctica, ya que gran parte del trabajo informático para romper la clave se puede realizar antes de que se establezca la conexión. El esfuerzo computacional requerido durante el intercambio de claves real toma alrededor de 70 segundos. Como medida de protección, los servidores deben desactivar la compatibilidad con conjuntos de cifrado exportables y utilizar grupos de al menos 2048 bits. Los clientes deben descartar los grupos que tengan menos de 1024 bits.

Error de implementación

Además de las debilidades de seguridad en el protocolo, las implementaciones de TLS se ven afectadas regularmente por errores de implementación relevantes para la seguridad. Uno de los errores más graves fue el error Heartbleed descubierto en OpenSSL en 2014 .

Violación pública y deliberada del cifrado

Se inició un ataque social al estándar TLS a través del ETSI , en el que se incorporará a los procesos generales de comunicación una versión del estándar que se puede cifrar y, por lo tanto, se puede considerar que no funciona.

Los atacantes obtienen una justificación para su ataque al cifrado del hecho de que debe haber oportunidades en los negocios, especialmente en la industria financiera, así como en las autoridades, para obtener una visión de alto nivel de la comunicación cifrada sin que los involucrados se den cuenta. eso. Muchos profesionales y organizaciones como B. la EFF advierte muy claramente contra el uso de este procedimiento debido a los posibles daños colaterales.

El intento de introducir este cifrado defectuoso en la familia TLS como "eTLS" ("Enterprise TLS") fue combatido por los derechos de denominación de TLS. razón por la cual el proceso pasará a llamarse ETS.

Dado que ETS / eTLS es reconocido como CVE por TLS, ETS / eTLS también puede describirse como una implementación defectuosa (deliberada) de TLS.

Como resultado, el Comité Técnico CYBER de ETSI 2019 recibió el BigBrotherAward negativo :