0criptográficos que proporcionan comunicaciones seguras por una red, comúnmente Internet.
Funcionamiento
Se usan certificados X.509 y por lo tanto criptografía asimétrica para autentificar a la contraparte con quien se están comunicando y para intercambiar una llave simétrica. Esta sesión es luego usada para encriptar el flujo de datos entre las partes. Esto permite la confidencialidad del dato/mensaje, y 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 voice-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.
TLS es un protocolo Internet Engineering Task Force (IETF), definido por primera vez en 1999 y actualizado por última vez en el RFC 5246 (agosto de 2008) y en RFC 6176 (marzo 2011). Se basa en las especificaciones previas de SSL (1994, 1995, 1996) desarrolladas por Netscape Communications4 para agregar el protocolo HTTPS a su navegador Netscape Navigator.
Descripción
SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, sólo 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: 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.
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. Éste 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.11. 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 encripte los datos (ver Cifrado). Entre los métodos utilizados para el intercambio/acuerdo de claves son: las claves públicas y privadas generadas con Diffie-Hellman anónimo (TLS_DH_anon),2 y PSK (TLS_PSK).
El método de acuerdo de claves TLS_DH_anon no autentica el servidor o el y por lo tanto rara vez se utiliza puesto que es vulnerable a un ataque de suplantación de identidad. Sólo 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 de la encriptación TLS que proporciona a sus s.
Comentarios