TLS: cómo se encripta en Internet

TLS (Transport Layer Security) es un protocolo de cifrado que garantiza la tra­n­s­mi­sión segura de datos en Internet. Es el sucesor del ya obsoleto SSL y, en la ac­tua­li­dad, se utiliza casi ex­clu­si­va­me­n­te en su versión TLS 1.3.

¿Qué es TLS?

En los primeros años de Internet, la seguridad de los datos no era una prioridad como lo es hoy. Toda la co­mu­ni­ca­ción se tra­n­s­mi­tía de forma abierta y sin cifrar entre or­de­na­do­res, algo parecido a enviar una postal: cualquier persona que la tra­n­s­po­r­ta­ra podía leer su contenido.

Con la llegada del protocolo TLS, también conocido como SSL/TLS, se introdujo el cifrado de los datos tra­n­s­mi­ti­dos. Siguiendo con el mismo ejemplo, este cifrado sería como meter la postal en un sobre sellado que solo puede abrir el de­s­ti­na­ta­rio legítimo.

TLS es el acrónimo de Transport Layer Security, que se traduce al español como “seguridad de la capa de tra­n­s­po­r­te”. Esta de­no­mi­na­ción hace re­fe­re­n­cia a la capa de tra­n­s­po­r­te del modelo TCP/IP. TLS es un proceso que encripta los flujos de datos de Internet para que solo sus legítimos de­s­ti­na­ta­rios puedan leerlos.

¿Cómo funciona TLS?

TLS encripta por cifrado simétrico todo el tráfico de datos que se realiza a través de TCP.

Aunque suene fácil en la práctica, la realidad es más co­m­pli­ca­da. El problema principal es que el servidor debe comunicar la clave al cliente y, además, debe hacerlo antes de que la co­mu­ni­ca­ción se asegure con TLS. Si envías ha­bi­tua­l­me­n­te archivos cifrados por correo, conocerás este problema: cifras un archivo y después debes compartir la co­n­tra­se­ña con el de­s­ti­na­ta­rio, por ejemplo, por teléfono.

El protocolo TLS, cuya versión actual es la 1.3 desde 2018, emplea el siguiente pro­ce­di­mie­n­to para ga­ra­n­ti­zar una conexión segura:

1. Clie­n­tHe­llo: el cliente (por ejemplo, un navegador) inicia la conexión enviando un mensaje llamado Clie­n­tHe­llo, que contiene in­fo­r­ma­ción sobre los métodos de cifrado que admite. Entre estos datos se incluyen las cipher suites, las versiones del protocolo, un valor aleatorio y su propio valor de in­te­r­ca­m­bio de claves de Diffie-Hellman (valor ECDHE). Op­cio­na­l­me­n­te, puede incluir ya un primer bloque de datos cifrado.
2. Se­r­ve­rHe­llo: el servidor responde con un mensaje llamado Se­r­ve­rHe­llo, en el que se­le­c­cio­na los pa­rá­me­tros adecuados y responde con su propia in­fo­r­ma­ción, que incluye su valor ECDHE y su ce­r­ti­fi­ca­do digital. Este ce­r­ti­fi­ca­do SSL confirma que el servidor es auténtico y no está su­pla­n­ta­n­do una identidad. Al mismo tiempo, comienza el cálculo de la clave de sesión.
3. Cálculo de claves: ambas partes calculan de forma in­de­pe­n­die­n­te la misma clave de sesión (session key) a partir de la clave pre­via­me­n­te acordada.
4. El servidor completa el in­te­r­ca­m­bio inicial y comienza la co­mu­ni­ca­ción cifrada. El cliente hace lo mismo y, a partir de ese momento, la conexión queda to­ta­l­me­n­te asegurada.

El motivo por el que la cri­p­to­gra­fía asi­mé­tri­ca con Diffie Hellman solo se utiliza para la tra­n­s­mi­sión de la clave de sesión (pero no para el cifrado del flujo de datos en sí) es la de­s­ve­n­ta­ja que supone en la velocidad: la cri­p­to­gra­fía asi­mé­tri­ca es re­la­ti­va­me­n­te lenta y re­tra­sa­ría la co­mu­ni­ca­ción de datos.

Pros y contras de TLS

TLS es una solución sencilla para hacer más seguro el tráfico de datos en la web, pues no requiere que las partes cifren por sí mismas el contenido, como pueden ser los datos de un fo­r­mu­la­rio. En su lugar, basta con que el tráfico se produzca a través del TLS protocol, in­de­pe­n­die­n­te­me­n­te del sistema operativo y de las apli­ca­cio­nes in­fo­r­má­ti­cas que utilicen los in­vo­lu­cra­dos. Durante la tra­n­s­mi­sión, todos los flujos de datos se cifran de forma au­to­má­ti­ca.

El precio de esta seguridad es una conexión li­ge­ra­me­n­te más lenta, ya que las etapas del proceso que acabamos de describir —ce­r­ti­fi­ca­do, número aleatorio e in­te­r­ca­m­bio de claves— es muy exigente a nivel co­mpu­tacio­nal.

Campos de apli­ca­ción de TLS

Tal y como hemos explicado, TLS se puede utilizar de forma universal, sin importar la apli­ca­ción ni el sistema operativo. Como co­n­se­cue­n­cia, son muchos los pro­to­co­los de apli­ca­ción que cuentan con una versión segura de TLS. El esquema de de­no­mi­na­ción es, en muchos casos, muy sencillo: cuando un protocolo utiliza TLS, si­m­ple­me­n­te se añade una “S” al final de su nombre.

El ámbito de apli­ca­ción más im­po­r­ta­n­te de TLS es la World Wide Web o, más co­n­cre­ta­me­n­te, el protocolo HTTP. Su variante cifrada recibe el nombre de HTTPS.

Otros casos de apli­ca­ción ha­bi­tua­les son:

• POP3S: los correos ele­c­tró­ni­cos desde el servidor se reciben con el protocolo POP3.
• IMAPS: la bandeja de entrada se si­n­cro­ni­za con el servidor uti­li­za­n­do el protocolo IMAP.
• SMTPS: envío de correos ele­c­tró­ni­cos.
• FTPS: tra­n­s­fe­re­n­cia de archivos a través del protocolo FTP.
• SIPS: telefonía de voz sobre IP uti­li­za­n­do el protocolo SIP.
• IRCS: chats cifrados.
• QUIC: protocolo de tra­n­s­po­r­te de­sa­rro­lla­do por Google que integra di­re­c­ta­me­n­te TLS 1.3; se presenta como una al­te­r­na­ti­va a TCP para lograr co­ne­xio­nes web más rápidas y seguras (por ejemplo, en HTTP/3)

OpenVPN, un software libre para es­ta­ble­cer una red privada virtual (VPN), también utiliza el TLS protocol.

Apli­ca­cio­nes de TLS

Algunas apli­ca­cio­nes im­po­r­ta­n­tes de TLS son:

• OpenSSL: de lejos, su apli­ca­ción más habitual, ya que la mayoría de las páginas web utilizan HTTPS.
• GnuTLS: de­sa­rro­lla­da por la Free Software Fou­n­da­tion*.*
• LibreSSL: de­sa­rro­lla­da por OpenBSD.
• NSS: de­sa­rro­lla­da por Network Security Services*.*
• BoringSSL: de­sa­rro­lla­da por Google.
• Rustls: de­sa­rro­lla­da por Joe Birr-Pixton, Dirkjan Ochtman, Daniel McCarney, Josh Aas y la comunidad de código abierto.
• Botan: licencia de BSD, de­sa­rro­lla­da por Jack Lloyd.
• JSSE: de­sa­rro­lla­da por Java Secure Socket Extension y Oracle.
• S2n: de­sa­rro­lla­da por Amazon.

Esta lista no es exhau­s­ti­va. En­co­n­tra­rás más in­fo­r­ma­ción sobre los usos de TLS en el artículo de Wikipedia “Co­m­pa­ra­ción de im­ple­me­n­ta­cio­nes TLS”.

Ataques conocidos a TLS

TLS no está to­ta­l­me­n­te a salvo de los ataques y de las fi­l­tra­cio­nes. Algunos puntos de ataque conocidos son:

• Errores de pro­gra­ma­ción: como la famosa brecha de seguridad Hea­r­t­bleed, un grave error de pro­gra­ma­ción en las primeras versiones de OpenSSL, que se corrigió en 2014.
• En­cri­p­ta­ción débil: como co­n­se­cue­n­cia de las re­s­tri­c­cio­nes es­ta­dou­ni­de­n­ses de ex­po­r­ta­ción de la cri­p­to­gra­fía, se de­sa­rro­lla­ron versiones ex­po­r­ta­bles más fáciles de descifrar que las ori­gi­na­les.
• Ataques de co­m­pre­sión: utilizar la co­m­pre­sión HTTP en vez de la co­m­pre­sión TLS hace que a los piratas in­fo­r­má­ti­cos les resulte más fácil adivinar el contenido cifrado con TLS mediante distintos procesos.
• El ataque BEAST afectó a la versión 1.0 de TLS y ya se describió en 2014. Las versiones actuales de TLS son más seguras frente a ese tipo de ataques.
• El *ataque Padding Oracle se descubrió en 2002 y no se corrigió hasta la versión 3.0 de SSL. La versión actual 1.3 de TLS no se ve afectada.
• El ataque ALPACA, de­s­cu­bie­r­to en 2021, demuestra cómo se pueden explotar ce­r­ti­fi­ca­dos TLS en se­r­vi­do­res mal co­n­fi­gu­ra­dos para redirigir a los usuarios a otros servicios y así in­te­r­ce­p­tar o manipular datos.

Además, se trató de evitar la aparición de un cifrado TLS co­m­ple­ta­me­n­te seguro para que las au­to­ri­da­des pudiesen in­s­pe­c­cio­nar co­mu­ni­ca­cio­nes cifradas, por ejemplo, si estaban re­la­cio­na­das con tra­n­sac­cio­nes fi­na­n­cie­ras o ac­ti­vi­da­des de­li­c­ti­vas. Una de las or­ga­ni­za­cio­nes que más trabajó para que TLS tuviese un punto débil de este tipo fue el ETSI (Instituto Europeo de Normas de Te­le­co­mu­ni­ca­cio­nes).