¿Qué es TLS y cómo funciona?

Transport Layer Security (TLS) es uno de los protocolos de seguridad más importantes y ampliamente utilizados. Protege una proporción significativa de los datos que se transmiten en línea. Es más prominente se utiliza para proteger los datos que viajan entre un navegador web y un sitio web a través de HTTPS, pero también se puede usar para proteger el correo electrónico y una gran cantidad de otros protocolos.

TLS es valioso porque garantiza que la otra parte en una conexión sea quien dice ser, muestra si los datos conservan su integridad inicial y proporciona confidencialidad a través del cifrado.

TLS utiliza una variedad de algoritmos y esquemas diferentes para lograr estos propósitos. Puede parecer complicado, pero este artículo cubrirá un aspecto a la vez para darle una mirada en profundidad sobre cómo funciona TLS para asegurar las conexiones.

¿Qué hace TLS??

Al enviar información en línea, nos encontramos con tres problemas principales de seguridad:

• ¿Cómo podemos saber si la persona con la que nos estamos comunicando es realmente quien dice ser??
• ¿Cómo podemos saber que los datos no han sido alterados desde que los enviaron??
• ¿Cómo podemos evitar que otras personas vean y accedan a los datos??

Estos problemas son cruciales, especialmente cuando enviamos información sensible o valiosa. TLS utiliza una variedad de técnicas criptográficas para abordar cada uno de estos tres problemas. Juntos, permiten que el protocolo autenticar a la otra parte en una conexión, verificar la integridad de los datos y proporcionar protección cifrada.

Simplifiquemos las cosas y simulemos que está intentando transferir información de un lado a otro con un amigo que vive en todo el país. Si la información es delicada, estará muy preocupado por los tres problemas principales mencionados anteriormente.

No puede enviar una carta y esperar lo mejor, especialmente si sospecha que sus comunicaciones serán atacadas por atacantes. En cambio, necesita un sistema que le permita verificar que su destinatario sea legítimo, una forma de verificar si los mensajes han sido alterados y una forma de protegerlos de miradas indiscretas..

TLS cumple estos requisitos utilizando una serie de procesos diferentes. Comienza con lo que se conoce como Apretón de manos TLS, que es donde se lleva a cabo la autenticación y se establecen las claves.

Para volver a nuestra analogía de cartas, la parte de autenticación de TLS sería como enviar una carta a través de un servicio de mensajería que requiere identificación. Cuando el mensajero entrega la carta, compararían la identificación de la persona con su cara y verificarían si el destinatario era la persona correcta o no..

La fase de establecimiento de la clave sería un poco como si su carta contuviera la mitad de un número PIN que pretendía utilizar en futuras comunicaciones. Le pediría a su destinatario que presente la segunda mitad del número y se la envíe en su carta de respuesta..

Una vez que el servicio de mensajería haya verificado la identidad y se haya establecido el número PIN, tendrá todo lo que necesita para enviar información de forma segura. En realidad, estas etapas son mucho más complejas, pero llegaremos a eso más adelante.

TLS intercambia información de forma segura con el protocolo de aplicación. Para continuar con nuestra analogía, transmitir datos de forma segura a través de TLS sería como escribir un mensaje y ponerlo en un sobre. Debería escribir su firma en el sello, de modo que si la carta fue alterada, su destinatario podría distinguirla con la firma rasgada (esto en realidad se hace con matemáticas, pero nuevamente, lo cubriremos en profundidad más adelante).

Luego pondría la carta en una pequeña caja de metal que tenía un candado de combinación, estableciendo la combinación como el número de pin que estableció conjuntamente con su destinatario. Enviaría la caja a través del servicio de mensajería que verifica la identificación cuando se entregan los paquetes. Su destinatario respondería de la misma manera, y cualquier comunicación futura seguiría los mismos pasos.

TLS resuelve nuestros tres problemas de una manera relativamente similar. El servicio de mensajería sirve para autenticar al destinatario y asegurarse de que la caja se entregue a la persona destinataria. El cuadro bloqueado sirve como una forma de cifrado, evitando que cualquier persona que no sea su compañero acceda a las cartas. El sobre firmado le permite saber si el mensaje no ha sido manipulado.

Esta es una aproximación muy aproximada de lo que hace TLS. En realidad, TLS tiene lugar entre clientes y servidores, en lugar de dos personas que se envían correos entre sí. La analogía es solo para darle una visualización de lo que está sucediendo y el razonamiento detrás de esto. En las siguientes secciones, cubriremos lo que realmente sucede en detalle.

TLS vs. SSL

Al leer sobre TLS, a menudo verá mención de SSL o incluso como TLS / SSL. Secure Sockets Layer (SSL) es la versión anterior de TLS, pero muchos en la industria todavía se refieren a TLS bajo el antiguo nombre. Este artículo usará el término TLS en todas partes, pero es importante tener en cuenta que los nombres a menudo se usan indistintamente. Puedes leer más sobre SSL en nuestra guía.

La historia de TLS

Todo comenzó con la necesidad de asegurar la capa de transporte. Como mencionamos anteriormente, el precursor de TLS fue SSL. Las primeras versiones de SSL fueron desarrolladas en los años noventa por Netscape, una compañía que construyó uno de los primeros navegadores web.

SSL 1.0 nunca se lanzó porque contenía vulnerabilidades graves. La versión 2.0 salió con Netscape Navigator 1.1 en 1995, Sin embargo, todavía contenía una serie de fallas graves. SSL 3.0 fue una versión fuertemente rediseñada y salió en 1996, con muchos de los problemas de seguridad resueltos.

En 1996, El IETF lanzó un borrador de SSL 3.0 en RFC 6101. El IETF formó un grupo de trabajo para estandarizar SSL, publicando los resultados en 1999 como TLS 1.0. Fue documentado en RFC 2246 y la estandarización incluyó algunos cambios al protocolo original, así como el cambio de nombre. Estas modificaciones se produjeron como resultado de negociaciones entre Netscape, Microsoft y el grupo de trabajo IETF.

En 2006, el IETF lanzó RFC 4346, que documenta TLS 1.1. Esta versión contenía nuevas disposiciones de seguridad y una serie de otras actualizaciones. La versión 1.2 se lanzó solo dos años más tarde en 2008. Incluyó soporte para cifrados de cifrado autenticado, una serie de cambios en la forma en que se utilizaron las funciones hash y muchas otras mejoras.

La próxima versión no llegó hasta 2023, cuando se definió TLS 1.3. Presenta una gran cantidad de cambios, incluido el secreto forzado, la eliminación de la compatibilidad con algoritmos más débiles y mucho más..

TLS 1.0 y 1.1 ahora están en desuso en 2023, pero la versión 1.2 está en uso generalizado. La versión 1.3 está comenzando a ver una mayor adopción.

TLS: los detalles técnicos

TLS consta de muchos elementos diferentes. La parte fundamental es el protocolo de registro, el protocolo subyacente responsable de la estructura general de todo lo demás..

Diagrama que muestra la pila TLS. Pila de protocolos TLS de Jeffreytedjosukmono. Licenciado bajo CC0.

El protocolo de registro contiene cinco subprotocols separados, cada uno de los cuales está formateado como registros:

• Apretón de manos – Este protocolo se utiliza para configurar los parámetros para una conexión segura.
• Solicitud – El protocolo de aplicación comienza después del proceso de protocolo de enlace, y es donde los datos se transmiten de forma segura entre las dos partes..
• Alerta – El protocolo de alerta es utilizado por cualquiera de las partes en una conexión para notificar a la otra si hay algún error, problemas de estabilidad o un posible compromiso..
• Cambiar especificaciones de cifrado – Este protocolo lo utiliza el cliente o el servidor para modificar los parámetros de cifrado. Es bastante sencillo, por lo que no lo cubriremos en profundidad en este artículo.
• Latido del corazón – Esta es una extensión TLS que le permite a un lado de la conexión saber si su par aún está vivo y evita que los firewalls cierren conexiones inactivas. No es una parte central de TLS, por lo que lo omitiremos en esta guía.

Cada uno de estos subprotocols se utiliza en diferentes etapas para comunicar información diferente. Los más importantes para entender son el protocolo de enlace y los protocolos de aplicación, ya que son responsables de establecer la conexión y luego transmitir los datos de forma segura.

El protocolo de enlace TLS

Aquí es donde se establece la conexión de manera segura. Puede parecer complejo si es nuevo en algunos de los conceptos, pero cada uno de estos se trata más adelante en el artículo si necesita consultarlos..

Hay tres tipos básicos de protocolo de enlace TLS: el apretón de manos básico TLS, el protocolo de enlace TLS autenticado por el cliente y el apretón de manos abreviado.

El apretón de manos básico de TLS

Diagrama que muestra el proceso de apretón de manos TLS. Apretón de manos completo TLS 1.2 por FleshGrinder. Licenciado bajo CC0.

En este tipo de protocolo de enlace, solo el servidor está autenticado y no el cliente. Comienza con la fase de negociación, donde un cliente envía un Cliente hola mensaje. Contiene la versión más alta de TLS que admite el cliente, posibles conjuntos de cifrado, una indicación de si admite compresión, un número aleatorio y alguna otra información

El mensaje de saludo del cliente se encuentra con un Servidor hola mensaje. Esta respuesta contiene el ID de sesión, la versión del protocolo, el conjunto de cifrado y la compresión (si se está utilizando) que el servidor seleccionó de la lista del cliente. También incluye un número aleatorio diferente..

Depende del conjunto de cifrado que se haya seleccionado, pero el servidor generalmente lo seguirá enviando un Certificado mensaje de autenticación. Esto valida su identidad y contiene su clave pública.

Si se utilizan intercambios de claves efímeros de Diffie-Hellman o anónimos de Diffie-Hellman, esto es seguido por un Server Key Exchange mensaje. Otros métodos de intercambio de claves omiten esta parte. Cuando el servidor ha terminado con su lado de la negociación, envía un Servidor Hola Hecho mensaje.

Ahora es el turno del cliente nuevamente. Dependiendo del conjunto de cifrado elegido, enviará un Intercambio de clave de cliente mensaje. Esto puede contener una clave pública o un secreto previo al maestro, que se cifra con la clave pública del servidor.

Ambas partes usan los números aleatorios y el secreto premaster para crear un secreto maestro. Las claves se derivan del secreto maestro, que luego se utilizan para autenticar y cifrar las comunicaciones..

El cliente luego envía un Cambiar especificaciones de cifrado mensaje. Esto le dice al servidor que los siguientes mensajes ahora se autenticarán y cifrarán (aunque a veces no se puede usar el cifrado).

El cliente luego sigue esto con un Terminado mensaje, que está encriptado y también contiene un Código de autenticación de mensaje (MAC) para la autenticación. El servidor descifra este mensaje y verifica el MAC. Si alguno de estos procesos falla, entonces la conexión debe ser rechazada.

Ahora es el turno del servidor para enviar un Cambiar especificaciones de cifrado mensaje, así como un Terminado mensaje con el mismo contenido que el anterior. El cliente también intenta descifrar y verificar el contenido. Si todo esto se completa con éxito, el apretón de manos habrá finalizado. En este punto, se establece el protocolo de aplicación. Los datos se pueden intercambiar de forma segura de la misma manera que Terminado mensaje desde arriba, con autenticación y cifrado opcional.

Apretón de manos TLS autenticado por el cliente

Este protocolo de enlace es muy similar al protocolo de enlace básico de TLS, pero el cliente también está autenticado. La principal diferencia es que después de que el servidor envía su Certificado mensaje, también envía un Solicitud de certificado mensaje, solicitando el certificado del cliente. Una vez que el servidor está terminado, el cliente envía su certificado en un Certificado mensaje.

El cliente luego envía su Intercambio de clave de cliente mensaje, al igual que en el apretón de manos básico de TLS. Esto es seguido por el Certificado de verificación mensaje, que incluye la firma digital del cliente. Como se calcula a partir de la clave privada del cliente, el servidor puede verificar la firma utilizando la clave pública que se envió como parte del certificado digital del cliente. El resto de Apretón de manos TLS autenticado por el cliente sigue la misma línea que el apretón de manos básico de TLS.

Apretón de manos TLS abreviado

Una vez que ya ha tenido lugar un apretón de manos, TLS permite que gran parte del proceso se corte mediante el uso de un apretón de manos abreviado. Estos apretones de manos utilizan la ID de sesión para vincular la nueva conexión a los parámetros anteriores..

Un apretón de manos abreviado permite a ambas partes reanudar la conexión segura con la misma configuración que se negoció anteriormente. Debido a que parte de la criptografía que normalmente está involucrada en el inicio de un apretón de manos puede ser bastante pesada en recursos computacionales, esto ahorra tiempo y facilita la conexión.

El proceso comienza con el Cliente hola mensaje. Es muy parecido al mensaje anterior de saludo del cliente, pero también contiene el ID de sesión de la conexión anterior. Si el servidor conoce la ID de sesión, la incluye en su Servidor hola mensaje. Si no reconoce la ID de la sesión, devolverá un número diferente y, en su lugar, tendrá que realizarse un apretón de manos TLS completo..

Si el servidor reconoce la ID de sesión, entonces el Certificado y Intercambio de llaves Se pueden omitir los pasos. los Cambiar especificaciones de cifrado y Terminado los mensajes se envían de la misma manera que el apretón de manos básico de TLS que se muestra arriba. Una vez que el cliente ha descifrado el mensaje y verificado el MAC, los datos se pueden enviar a través de la conexión segura TLS.

También hay una extensión TLS que permite reanudar las conexiones con tickets de sesión en lugar de identificadores de sesión. El servidor cifra los datos sobre la sesión y los envía al cliente. Cuando el cliente desea reanudar esta conexión, envía el ticket de sesión al servidor, que lo descifra para revelar los parámetros.

Los tickets de sesión no se usan con tanta frecuencia porque requieren la extensión. A pesar de esto, pueden ser ventajosos en ciertas situaciones, porque el servidor no tiene que almacenar nada.

Desembalaje del apretón de manos TLS

Los tres pasos más importantes del apretón de manos incluyen:

• los parámetros son seleccionados,
• lleva a cabo la autenticación y
• las llaves están establecidas.

Vamos a cubrirlos con un poco más de detalle para que pueda entender lo que realmente está sucediendo..

Los parametros

Al comienzo del apretón de manos, el cliente y el servidor negocian los parámetros de la conexión de común acuerdo. El primero de ellos es qué versión de TLS se utilizará. Esta es la versión más alta que ambas partes admiten, que tiende a ser la más segura..

Las partes también deciden qué algoritmo de intercambio de claves utilizarán para establecer la clave maestra. La función hash, el algoritmo de cifrado y el método de compresión también se acuerdan en esta etapa. Estos serán cubiertos en detalle cuando discutamos el Protocolo de aplicación más adelante en el artículo.

Autenticación: certificados digitales

La autenticación es una parte clave para asegurar un canal de comunicación, porque les permite a ambas partes saber que en realidad están hablando con quienes creen que son y no con un impostor. En TLS y muchos otros mecanismos de seguridad, esto se logra con lo que se conoce como certificados digitales..

Los certificados digitales son documentos electrónicos que muestran el vínculo entre un individuo o entidad y su clave pública.. Este enlace es validado por una autoridad de certificación (CA), que es una organización confiable que verifica que los dos están realmente relacionados, luego usa su propia reputación para otorgar confianza al certificado.   

Los diferentes niveles de certificado representan diversos grados de confianza. Lo importante es saber que si un cliente o un servidor tiene un certificado confiable y válido, entonces es razonable suponer que la clave pública es legítima y que no está tratando con un atacante.

Una nota sobre claves públicas

El cifrado de clave pública (también conocido como cifrado asimétrico) es una parte importante de la criptografía, y se usa ampliamente en los diferentes aspectos de TLS. Aquí hay una guía rápida para aquellos que no están familiarizados con su funcionamiento..

La breve explicación es que La criptografía de clave pública utiliza un par de claves para el cifrado y descifrado, en lugar de una sola clave. El remitente utiliza la clave pública del destinatario previsto para cifrar los datos. Una vez que se ha cifrado, solo se puede descifrar mediante la clave privada correspondiente del destinatario. Por supuesto, la clave pública se puede compartir públicamente, mientras que la clave privada debe mantenerse en secreto..

El cifrado de clave pública permite a las partes compartir información de forma segura, incluso si nunca se han reunido o han tenido la oportunidad de intercambiar claves de antemano. Lo hace a través de algunas propiedades únicas de los números primos. Puede encontrar más información en nuestro artículo sobre cifrado de clave pública.

Establecer un secreto maestro

Como vimos anteriormente cuando discutimos el proceso del apretón de manos básico de TLS, después de que una parte (o ambas partes) demuestre su identidad con su certificado público, el siguiente paso es establecer el secreto maestro, también conocido como secreto compartido. El secreto maestro es la base para derivar las claves utilizadas para cifrar y verificar la integridad de los datos transmitidos entre las dos partes..

El protocolo de enlace TLS puede usar varios mecanismos diferentes para compartir este secreto de forma segura. Estos incluyen RSA, varios tipos diferentes de intercambio de claves Diffie-Hellman, PSK, Kerberos y otros. Cada uno tiene sus propias ventajas y desventajas, como proporcionar confidencialidad directa, pero estas diferencias están fuera del alcance de este artículo.

El proceso exacto dependerá del método de intercambio de claves que se haya elegido, pero sigue los pasos generales mencionados en El apretón de manos básico de TLS sección.

El secreto premaster se deriva de acuerdo con el método de intercambio de claves que se haya seleccionado previamente. El cliente cifra el secreto premaster con la clave pública del servidor para enviarlo de forma segura a través de la conexión.

El cliente y el servidor usan el secreto premaster y los números aleatorios que enviaron al comienzo de la comunicación para obtener el secreto maestro. Una vez que se ha calculado la clave maestra, se utiliza para obtener cuatro o seis claves separadas. Estos son los:

• Cliente escribir clave MAC – El servidor utiliza esta clave para verificar la integridad de los datos enviados por el cliente.
• Servidor escribir clave MAC – El cliente utiliza la clave MAC de escritura del servidor para verificar la integridad de los datos enviados por el servidor.
• Clave de cifrado de escritura del cliente – El servidor usa esta clave para encriptar los datos enviados por el cliente.
• Clave de cifrado de escritura del servidor – El cliente usa esta clave para encriptar los datos enviados por el servidor.
• Cliente escribir clave IV – El servidor utiliza la clave IV de escritura del cliente en los cifrados AEAD, pero no cuando se utilizan otros algoritmos de intercambio de claves.
• Servidor escribir clave IV – Del mismo modo, el cliente utiliza esta clave en los cifrados AEAD, pero no cuando se utilizan otros algoritmos de intercambio de claves..

El establecimiento de la clave maestra es una parte importante del protocolo de enlace TLS, ya que permite que ambos lados de la conexión deriven claves de forma segura que se puedan usar tanto para la autenticación como para el cifrado. Se utilizan claves separadas para ambos procesos como medida de precaución..

Una vez que se han derivado las claves de autenticación y cifrado, se utilizan para proteger ambas Terminado mensajes, así como registros enviados a través del protocolo de aplicación.

El protocolo de aplicación

Una vez que el protocolo de enlace TLS ha establecido una conexión segura, el protocolo de aplicación se utiliza para proteger los datos transmitidos. Se puede configurar para usar una amplia gama de algoritmos para adaptarse a diferentes escenarios.

Algoritmos de autenticación

La integridad de los mensajes puede verificarse con muchos algoritmos diferentes. Éstos incluyen:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

Para probar la integridad de los datos que se envían, el remitente ejecuta la información a través de una función hash para devolver una cadena única de caracteres. Estas son fórmulas especiales que siempre devolverán el mismo resultado siempre que reciban la misma entrada.

El remitente firma estos datos con su clave privada para formar lo que se conoce como firma digital. La firma digital se adjunta al mensaje y se envía al destinatario. Para verificar si los datos conservan su integridad y no han sido alterados, el destinatario descifra el hash con la clave pública del remitente. Luego usan la misma función hash en los datos que se enviaron. El destinatario compara los dos valores..

Si son iguales, significa que los datos no se han modificado desde que el remitente los firmó. Si son diferentes, es probable que los datos hayan sido alterados o haya habido algún otro error.

Esa es la versión corta de cómo se pueden usar las funciones hash para mostrar la integridad de los datos. Si desea una comprensión más profunda, consulte nuestro artículo sobre cifrado, salazón y hash.

Algoritmos de cifrado

TLS utiliza cifrado de clave simétrica para proporcionar confidencialidad a los datos que transmite. A diferencia del cifrado de clave pública, solo se usa una clave en los procesos de cifrado y descifrado. Una vez que los datos se han cifrado con un algoritmo, aparecerá como una mezcla de texto cifrado. Mientras se utilice un algoritmo apropiado, los atacantes no podrán acceder a los datos reales, incluso si los interceptan..

TLS puede usar muchos algoritmos diferentes, como Camellia o ARIA, aunque el más popular es AES.

Compresión

La compresión es el proceso de codificación de datos para que ocupe menos espacio. TLS admite la compresión si ambos lados de la conexión deciden usarla. A pesar de esta capacidad, generalmente se recomienda evitar el uso de TLS para comprimir datos, especialmente desde el ataque CRIME (consulte el Problemas de seguridad de TLS sección a continuación) se descubrió que podía aprovechar los datos comprimidos para el secuestro de sesión.

Relleno

El relleno agrega datos adicionales a un mensaje antes de encriptarlo. Es un proceso criptográfico común que se utiliza para ayudar a evitar que las sugerencias en la estructura de los datos cifrados den su verdadero significado. TLS generalmente aplica el relleno PKCS # 7 a los registros antes de que se cifren.

Protocolo de alerta

Si la conexión o la seguridad se vuelven inestables, comprometidas o se ha producido un error grave, El protocolo de alerta permite al remitente notificar a la otra parte. Estos mensajes tienen dos tipos, ya sea de advertencia o fatales. Un mensaje de advertencia indica que la sesión es inestable y permite al destinatario determinar si la sesión debe continuar o no..

Un mensaje fatal le dice al destinatario que la conexión se ha visto comprometida o se ha producido un error grave. El remitente debe cerrar la conexión después de enviar el mensaje. El protocolo de alerta también contiene información sobre lo que está causando el problema de conexión particular. Esto puede incluir cosas como la falla de descifrado, una autoridad de certificación desconocida, un parámetro ilegal y mucho más.

TLS & el modelo OSI

El modelo OSI es una forma de conceptualizar y estandarizar cómo vemos nuestros diferentes sistemas y protocolos de comunicación. Es importante tener en cuenta que es solo un modelo, y algunos de nuestros protocolos no se ajustan a él..

Sin embargo, el OSI tiene siete capas separadas que muestran los niveles en los que operan los protocolos., TLS no cabe en ninguno. Fluye sobre otro protocolo de transporte como TCP, lo que debería implicar que está por encima de la cuarta capa, la capa de transporte. Se usa más prominentemente como una capa de transporte, pero debido a que realiza apretones de manos, esto implicaría que es parte de las capas de presentación o aplicación..

Como puede ver, TLS simplemente no se ajusta al modelo OSI. Esto no significa que TLS esté roto o mal, en todo caso, solo muestra que el modelo OSI es defectuoso y no puede dar cuenta de todos nuestros protocolos de comunicación..

Uso de TLS

TLS se utiliza para asegurar una proporción significativa de nuestras comunicaciones en línea. Normalmente se implementa sobre protocolos como el Protocolo de control de transmisión (TCP), pero también se puede usar en el Protocolo de control de congestión de datagramas (DCCP) y el Protocolo de datagramas de usuario (UDP).

Puede proteger protocolos como HTTP, SMTP, FTP, XMPP y NNTP, tan bien como otros. La aplicación más común es el Protocolo seguro de transferencia de hipertexto (HTTPS), que protege la conexión entre un navegador web y un sitio web. Puede saber cuándo se utiliza HTTPS para proteger su conexión en línea, porque aparecerá un pequeño ícono de candado verde a la izquierda de la URL en la parte superior de su navegador.

TLS también se puede usar para construir VPN, como en OpenConnect y OpenVPN. Utiliza sus capacidades de encriptación y autenticación para formar un túnel que puede conectar hosts y redes entre sí. Las tecnologías VPN basadas en TLS como OpenVPN son ventajosas sobre alternativas como IPsec, porque no se sabe que OpenVPN tenga problemas de seguridad graves. Estas VPN también pueden ser más fáciles de configurar.

Otro de sus usos es correo electrónico seguro a través de STARTTLS. Cuando se implementa TLS, evita que los atacantes puedan acceder a los mensajes mientras viajan entre los servidores de correo.

Problemas de seguridad de TLS

Como la mayoría de los protocolos, TLS ha tenido una serie de vulnerabilidades pasadas y ataques teóricos contra sus diversas implementaciones. A pesar de esto, las últimas versiones se consideran seguras para fines prácticos.

Las versiones anteriores, como SSL 2.0 y 3.0 (y TLS 1.0, que es esencialmente lo mismo que SSL 3.0) presentan numerosas fallas de seguridad, pero como son protocolos antiguos y obsoletos, no entraremos en detalles. Debería usar TLS 1.2 y 1.3 para proteger sus conexiones.

Las versiones más recientes de TLS tienen numerosas actualizaciones que lo hacen menos vulnerable que SSL. A pesar de esto, el protocolo aún ha tenido los siguientes problemas de seguridad:

Ataques de renegociación

Una de las características de TLS es que permite que los pares cliente y servidor renegocien los parámetros de su conexión existente. En 2009, se descubrió que los atacantes podrían explotar esto para que puedan inyectar tráfico para que parezca que proviene del cliente. Los servidores aceptarán la solicitud como legítima, lo que significa que los atacantes podrían estar manipulando los mensajes salientes..

Este ataque no permite que el atacante vea la respuesta, pero aún tiene el potencial de ser dañino. Una extensión que evitará estos ataques es actualmente un estándar propuesto.

BESTIA

El ataque Exploit Browser Against SSL / TLS (BEAST) fue descubierto por primera vez por los investigadores en 2011. Aprovecha la vulnerabilidad de encadenamiento de bloque de cifrado en TLS, que se puede utilizar para descifrar mensajes. Este ataque solo afecta a TLS 1.0, que es una versión anterior y más débil del protocolo. Aunque no quedará en desuso hasta 2023, los usuarios deberían usar las versiones 1.2 y 1.3 en su lugar.

Ataques de tiempo

Estos ataques de canal lateral analizan cuánto tiempo tarda un algoritmo en ejecutarse, luego utilizan esa información para trabajar hacia atrás y descubrir la clave. En 2013, se descubrió que el ataque Lucky Thirteen aprovechaba tanto un ataque de tiempo como un ataque de oráculo de relleno mientras se verificaba el código de autenticación de mensaje (MAC). Este ataque puede usarse para romper el algoritmo TLS, aunque no se considera peligroso para la mayoría de los usuarios de TLS.

CRIMEN & INCUMPLIMIENTO

El ataque CRIME funciona contra una variedad de protocolos. Cuando los datos se han comprimido, puede obtener contenido de las cookies de autenticación. Esta información se puede utilizar para el secuestro de sesión. Si bien afecta a una serie de protocolos, el ataque es particularmente preocupante cuando se utiliza la compresión HTTP, ya que no existen estrategias efectivas de mitigación.

En 2013, se descubrió que el explorador Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) afectaba la compresión HTTP de manera similar. Esta versión del ataque puede recuperar direcciones de correo electrónico y otros datos valiosos que se cifraron con TLS. El ataque BREACH puede mitigarse deshabilitando la compresión HTTP o utilizando técnicas como la protección de falsificación de solicitudes entre sitios (CSRF).

Ataques de degradación

Estos son ataques que engañan a los servidores para que usen versiones anteriores y menos seguras de TLS. Los atacantes podrían usar estas técnicas para negociar el uso de intercambios de claves y cifrados menos seguros. El ataque Logjam es un buen ejemplo porque podría hacer que los servidores vulnerables usen Diffie-Hellman de 512 bits, que es débil. Los atacantes pueden romper este mecanismo de intercambio de claves y extraer las claves, lo que les permite un acceso completo a la sesión.

Heartbleed

Heartbleed fue una falla de seguridad que se introdujo accidentalmente en la biblioteca de criptografía OpenSSL en 2012, pero no se publicitó hasta 2014. Debido a que esta es una implementación tan utilizada de TLS, causó un daño global significativo.

Uno de los desarrolladores de la extensión de latido TLS agregó una vulnerabilidad de sobre-lectura de búfer, que permite exponer algunos datos adicionales. El error no se detectó cuando se revisó el código, lo que condujo a una serie de ataques significativos.

Dado que la biblioteca OpenSSL se implementa tan ampliamente, el costo internacional de mitigar el problema terminó siendo bastante costoso. Los administradores del servidor tuvieron que instalar el nuevo parche y regenerar certificados y pares de claves que pueden haber estado en peligro durante el período de dos años que existió la vulnerabilidad..

AHOGAR

El descifrado de RSA con el ataque de encriptación obsoleta y debilitada (DROWN) se anunció en 2016 y aprovecha el soporte del servidor para SSL 2.0. Utiliza un ataque de texto cifrado elegido contra servidores que aún admiten SSL 2.0, así como aquellos que comparten el mismo certificado de clave pública con otro servidor que admite SSL 2.0.

Cuando se anunció el ataque, podría lanzarse con costos iniciales de configuración de alrededor de $ 18,000 y alrededor de $ 400 por cada ataque por separado. Cuando el ataque DROWN es exitoso, adquiere las claves de sesión.

El ataque puede mitigarse al no compartir certificados del servidor. El grupo OpenSSL también ha lanzado parches que eliminan la compatibilidad con protocolos y cifrados más antiguos, pero estos solo funcionan si el certificado del servidor no se comparte con otros servidores que admiten SSL 2.0.

PAC impío

Este ataque se encontró en 2016. Aprovecha las debilidades encontradas en el Protocolo de detección automática de proxy web (WPAD). Cuando un usuario intenta visitar un sitio web a través de una conexión cifrada TLS, la falla puede hacer que la URL sea visible. Dado que las URL a veces se envían a los usuarios como una forma de autenticación, el ataque Unholy PAC hace posible que un atacante se haga cargo de la cuenta de un usuario.

¿TLS es seguro??

Si bien puede parecer que hay muchos problemas de seguridad, la realidad es que la mayoría de estos son bastante menores y pueden o han sido mitigados. A medida que avanza la tecnología, se descubren vulnerabilidades y se desarrollan nuevos ataques, TLS continuará teniendo más problemas de seguridad. A pesar de esto, por ahora y en el futuro previsible, parece que TLS seguirá siendo una de las herramientas principales y más confiables que usaremos para asegurar nuestro mundo en línea..

Tecnología empresarial de ciberseguridad por TheDigitalArtist con licencia bajo CC0