Seguridad de la capa de transporte (, TLS) y su antecesor Secure Sockets Layer (SSL; en español capa de puertos seguros) son protocolos criptográficos, que proporcionan comunicaciones seguras por una red, comúnmente Internet. El protocolo TLS es el sucesor de SSL (1995), introducido en 1999 con una versión mejorada de SSL 3.0 (que al principio se llamó SSL 3.1). La versión actual es TLS 1.3 (a partir de 2018). Las versiones de SSL están desactualizadas y se consideran inseguras. Se usan certificados X.509, y por lo tanto criptografía asimétrica para autenticar a la contraparte con quien se están comunicando, y para intercambiar una clave simétrica. Esta sesión es luego usada para cifrar el flujo de datos entre las partes. Esto permite la confidencialidad del mensaje, códigos de autenticación de mensajes para integridad y como un producto lateral, autenticación del mensaje. Varias versiones del protocolo están en aplicaciones ampliamente utilizadas como navegación web, correo electrónico, fax por Internet, mensajería instantánea y voz-sobre-IP (VoIP). Una propiedad importante en este contexto es forward secrecy, para que la clave de corta vida de la sesión no pueda ser descubierta a partir de la clave asimétrica de largo plazo.SSL: Intercepted today, decrypted tomorrow, Netcraft, 2013-06-25.

TLS es un protocolo de Internet Engineering Task Force (IETF), definido por primera vez en 1999, que fue actualizado en el RFC 5246 (agosto de 2008) y en RFC 6176 (marzo de 2011). Se basa en las especificaciones previas de SSL (1994, 1995, 1996) desarrolladas por Netscape Communications para agregar el protocolo HTTPS a su navegador Netscape Navigator. Su última versión, TLS 1.3, fue definida en agosto de 2018.

Descripción

SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, solo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.

SSL implica una serie de fases básicas:

Negociar entre las partes el algoritmo que se usará en la comunicación Intercambio de claves públicas y autenticación basada en certificados digitales. Cifrado del tráfico basado en cifrado simétrico.

Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones: Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza. Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES y AES (Advanced Encryption Standard). Con funciones hash: MD5 o de la familia SHA.

Historia y desarrollo Protocolo Publicación SSL 1.0 SSL 2.0 1995 SSL 3.0 1996 TLS 1.0 1999 TLS 1.1 2006 TLS 1.2 2008 TLS 1.3 2018 API de Secure Network Programming

Los primeros esfuerzos de investigación hacia la seguridad de la capa de transporte incluyeron la interfaz de programación de aplicaciones (API, por su sigla en inglés) de Secure Network Programming (SNP), la que en 1993 exploró la posibilidad de tener una API de capa de transporte segura similar a los sockets Berkeley, para facilitar la retroadaptación de las aplicaciones de red preexistentes con medidas de seguridad.Woo, Thomas Y. C., Raghuram Bindignavle, Shaowen Su y Simon S. Lam, SNP: An interface for secure network programming Proceedings USENIX Summer Technical Conference, June 1994

SSL 3.0

El protocolo SSL fue desarrollado originalmente por Netscape. La versión 1.0 nunca se entregó públicamente; la versión 2.0 se presentó en febrero de 1995 pero "contenía una cantidad de fallas de seguridad que al final llevaron al diseño de la versión SSL 3.0".Rescorla 2001 Dicha versión, presentada en 1996, fue un rediseño completo del protocolo producido por Paul Kocher, quien trabajó con los ingenieros de Netscape Phil Karlton y Alan Freier. Las versiones más nuevas de SSL/TLS están basadas en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por la IETF como el histórico RFC 6101. En octubre de 2014, se detectó una nueva vulnerabilidad sobre el protocolo SSL en su versión 3.0, la Vulnerabilidad de Poodle.

TLS 1.0

TLS 1.0 fue definido en el RFC 2246 en enero de 1999 y es una actualización de SSL versión 3.0. Como dice el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dramáticas, pero son suficientemente significativas como para impedir la interoperabilidad entre TLS 1.0 y SSL 3.0". TLS 1.0 incluye una forma en la cual la implementación puede conectarse en SSL 3.0, debilitando la seguridad.

TLS 1.1

TLS 1.1 fue definido en el RFC 4346 en abril de 2006. Es una actualización de TLS 1.0. Las diferencias más significativas incluyen: Agrega protección contra ataques de CBC. El vector de inicialización (IV) implícito fue reemplazado por un IV explícito. Cambio en el manejo de los errores de relleno. Soporte para el registro de parámetros de IANA.

TLS 1.2

TLS 1.2 fue definido originalmente en el RFC 5246 en agosto del 2008. Se basa en una especificación posterior de TLS 1.1. Las mayores diferencias son: la combinación MD5-SHA-1 en la función pseudoaleatoria (PRF) fue reemplazada por SHA-256, con la opción de usar las PRF especificadas en la cipher-suite. la combinación MD5-SHA-1 en el mensaje terminado fue reemplazada por SHA-256, sin la opción de usar algoritmos de hash específicos para la cipher-suite. Sin embargo, el tamaño del hash en el mensaje terminado es truncado a 96 bits. la combinación MD5-SHA-1 en el elemento digitalmente firmado fue reemplazada por un hash simple negociado durante el handshake, que por defecto es SHA-1. Mejoras en la habilidad de clientes y servidores para especificar qué algoritmos de hash y de firma van a aceptar. Expansión del soporte de cifras de cifrado autenticadas, usadas mayormente para modo Galois/Counter (GCM) y modo CCM del cifrado con Advanced Encryption Standard (AES). Se agregaron definición de Extensiones de TLS y de Ciphersuites de AES. TLS 1.2 fue después redefinido en el RFC 6176 de marzo de 2011 redactando su retrocompatibilidad con SSL y TLS para que dichas sesiones jamás negocien el uso de SSL versión 2.0.

TLS 1.3 TLS 1.3 fue definido en el RFC 8446 en agosto de 2018. Está basado en la anterior especificación TLS 1.2. Las principales diferencias con TLS 1.2 incluyen: Un modo 0-RTT Retiro de la hora GMT. Fusiona soporte de ECC del RFC 4492 pero sin curvas explícitas. Retira el campo de longitud innecesaria de la entrada de AD a cifras AEAD. Cambiar el nombre de {Cliente, Servidor} KeyExchange a {Cliente, Servidor} KeyShare Añade un HelloRetryRequest explícita para rechazar el del cliente Handshake revisado a fin de proporcionar el modo 1-RTT. Retiro de grupos DHE personalizados. Eliminado el soporte para la compresión. Eliminado el soporte para el intercambio de claves RSA estática y DH. Eliminado el soporte para sistemas de cifrado no AEAD.

Funcionamiento

El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser comprimido, cifrado y empaquetado con un código de autenticación del mensaje (MAC). Cada registro tiene un campo de content_type que especifica el protocolo de nivel superior que se está usando.

Cuando se inicia la conexión, el nivel de registro encapsula otro protocolo, el protocolo handshake (o protocolo de acuerdo), que tiene el content_type 22.

El cliente envía y recibe varias estructuras handshake:

Envía un mensaje ClientHello especificando una lista de conjunto de cifrados, métodos de compresión y la versión del protocolo SSL más alta permitida. Este también envía bytes aleatorios que serán usados más tarde (llamados Challenge de Cliente o Reto). Además puede incluir el identificador de la sesión. Después, recibe un registro ServerHello, en el que el servidor elige los parámetros de conexión a partir de las opciones ofertadas con anterioridad por el cliente. Cuando los parámetros de la conexión son conocidos, cliente y servidor intercambian certificados (dependiendo de las claves públicas de cifrado seleccionadas). Estos certificados son actualmente X.509, pero hay también un borrador especificando el uso de certificados basados en OpenPGP.RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“ Cliente y servidor negocian una clave secreta (simétrica) común llamada master secret, posiblemente usando el resultado de un intercambio Diffie-Hellman, o simplemente cifrando una clave secreta con una clave pública que es descifrada con la clave privada de cada uno. Todos los datos de claves restantes son derivados a partir de este master secret (y los valores aleatorios generados en el cliente y el servidor), que son pasados a través una función pseudoaleatoria cuidadosamente elegida.

TLS/SSL poseen una variedad de medidas de seguridad: Numerando todos los registros y usando el número de secuencia en el MAC. Usando un resumen de mensaje mejorado con una clave (de forma que solo con dicha clave se pueda comprobar el MAC). Esto se especifica en el RFC 2104). Protección contra varios ataques conocidos (incluyendo ataques man-in-the-middle), como los que implican un degradado del protocolo a versiones previas (por tanto, menos seguras), o conjuntos de cifrados más débiles. El mensaje que finaliza el protocolo handshake (Finished) envía un hash de todos los datos intercambiados y vistos por ambas partes. La función pseudo aleatoria divide los datos de entrada en 2 mitades y las procesa con algoritmos hash diferentes (MD5 y SHA), después realiza sobre ellos una operación XOR. De esta forma se protege a sí mismo de la eventualidad de que alguno de estos algoritmos se revelen vulnerables en el futuro.

Intercambio de claves

Antes de que un cliente y el servidor pueden empezar a intercambiar información protegida por TLS, deben intercambiar en forma segura o acordar una clave de cifrado y una clave para usar cuando se cifren los datos (ver Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves son: las claves públicas y privadas generadas con RSA (denotado TLS_RSA en el protocolo de handshake TLS), Diffie-Hellman (llamado TLS_DH), Diffie-Hellman efímero (denotado TLS_DHE), Diffie-Hellman de Curva Elíptica (denotado TLS_ECDH), Diffie-Hellman de Curva Elíptica efímero (TLS_ECDHE), Diffie-Hellman anónimo (TLS_DH_anon), y PSK (TLS_PSK).

El método de acuerdo de claves TLS_DH_anon no verifica el servidor o el usuario y por lo tanto rara vez se utiliza puesto que es vulnerable a un ataque de suplantación de identidad. Solo TLS_DHE y TLS_ECDHE proporcionan secreto-perfecto-hacia-adelante.

Los certificados de clave pública que se utilizan durante el intercambio/acuerdo también varían en el tamaño de las claves de cifrado públicas/privadas utilizadas durante el intercambio y, por tanto, en la solidez de la seguridad que proveen. En julio de 2013, Google anunció que dejaría de utilizar claves públicas 1024 bits y cambiaría a claves de 2048 bits para aumentar la seguridad del cifrado TLS que proporciona a sus usuarios.

+ Autenticación e Intercambio/acuerdo de claves Algoritmo SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Estatus Definido para TLS 1.2 en RFCs rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! rowspan="2"! Propuesto en borradores RFC

Cifrado