A partir de ahora nos referiremos directamente a TLS, en concreto TLSv1.0 que es la evolución de SSL ( SSL 3.1). Actualmente y desde 1999 en que se establece como estándar IETF es el protocolo de conexión segura por autonomasia. Posteriormente aparecieron TLSv1.1 y TLSv1.2
TLS es un protocolo de 2 capas: TLS Record Protocol y una capa superior compluesta por protocolos que son encapsulados por la capa de registro: Handshake, Alert Protocol, Change cipher Spec y Application protocol.
El protocolo de registro (Record Protocol) se implementa sobre la capa TCP y tiene como 2 propiedades fundamentales que:
- Conexión privada con cifrado simétrico, basado en secreto compartido y negociado en el handshake. Puede usarse sin cifrado
- Conexión confiable: El transporte del mensaje usa un mensaje de chequeo de integridad que utiliza un MAC (Message Authentication Code) con clave, usando funciones de hash seguras como SHA y MD5, pero puede operar sin usarla.
Este protocolo encapsula protocolos de más alto nivel, como el HandShake Protocol.
Fundamentalmente se encarga de tomar los mensajes a ser transmitidos, fragmenta los datos en bloques manejables, opcionalmente comprime los datos, aplica una MAC, cifra y transmite el resultado. El dato recibido es desencriptado, verificado, descomprimido y reensamblado, entregándose a los clientes en niveles más altos. Este proceso se lleva a cabo mediante el uso de cuatro estados posibles de conexión : el estado de lectura actual, el estado de escritura actual, el estado pendiente de lectura y el estado pendiente de escritura. Cada estado especifica el algoritmo de compresión, el algoritmo de encriptación y el algoritmo de MAC, junto con el MAC con clave y el tamaño de las claves de encriptación.
Para cifrar los datos, el Record Protocol utiliza alguno de los siguientes algoritmos de criptografia simétrica: RC4, DES, IDEA,.
Fundamentalmente se encarga de tomar los mensajes a ser transmitidos, fragmenta los datos en bloques manejables, opcionalmente comprime los datos, aplica una MAC, cifra y transmite el resultado. El dato recibido es desencriptado, verificado, descomprimido y reensamblado, entregándose a los clientes en niveles más altos. Este proceso se lleva a cabo mediante el uso de cuatro estados posibles de conexión : el estado de lectura actual, el estado de escritura actual, el estado pendiente de lectura y el estado pendiente de escritura. Cada estado especifica el algoritmo de compresión, el algoritmo de encriptación y el algoritmo de MAC, junto con el MAC con clave y el tamaño de las claves de encriptación.
Para cifrar los datos, el Record Protocol utiliza alguno de los siguientes algoritmos de criptografia simétrica: RC4, DES, IDEA,.
El protocolo de Handshake es el que permite a las 2 partes autenticarse mutuamente y negociar el cifrado antes de intercambiar datos. Negocia y establece la conexión. Sus propiedades principales son:
- Autenticación asimétrica de al menos una de las dos partes
- Negociación del secreto compartido o premaster secret (simétrico) seguro, mediante técnicas de encriptación de clave pública (asimétricos). De ese premaster secret se derivará una clave simétrica común con la que se cifrarán los datos.
- Negociación confiable: no es posible una modificación sin que se ninguna de las dos partes se de cuenta de ello.
- Proporciona los parámetros de seguridad a la capa de registro (Record Protocol)
Para realizar el intercambio de claves, el Record Protocol utiliza los siguientes algoritmos: RSA, Diffie Hellman.
Como vemos , con este protocolo conseguimos una conexión segura gracias a la capa de Registro que nos proporciona la confidencialidad y la integridad y la capa de Handshake que pemite la autenticación.
Como vemos , con este protocolo conseguimos una conexión segura gracias a la capa de Registro que nos proporciona la confidencialidad y la integridad y la capa de Handshake que pemite la autenticación.
Seguridad
TLS/SSL implementa un buen número de medidas de seguridad:
- Protección contra un posible "downgrade" hacia una versión inferior del protocolo (menos segura).
- Numeración de los registros de Aplicación con un número de secuencia y uso de esta secuencia en los Mensajes de Autenticación de Codigo (MACs). Estos mensajes se crean empleando funciones de hash que protegen la integridad.Esto se especifica en el RFC2104
- Uso de funciones resumen hash potenciadas con el uso de clave de modo que solo el poseedor de la clave puede comprobar el MAC. Esto evita los ataques por colisión o Meet in The Middle
- El mensaje que finaliza el Handshake incluye un hash de todos los mensajes de handshake previamente intercambiados con lo que garantizamos la comunicación íntegra.
Handshake
Se pueden dar tres modalidades de Handshake a la hora de establecerse la comunicación entre el cliente y servidor:
- Handshake completo: Tanto el servidor como el cliente se intercambian certificados
- Handshake simple: Solo el servidor y no el cliente se autentica con entrega de su certificado
- Handshake resumido: Debido a que las operaciones con clave publica (generalmete RSA) son costosas computacionalmente, TLS incorpora un modo "resume" para evitar esas operaciones del handshake completo. En el establecimiento de una conexión el servidor y cliente intercambian un id de sesión que el cliente asociará con la IP y puerto del servidor de modo que cuando el cliente se reconecte usará ese id. El servidor comprobará que tiene en caché ese id de sesión ofrecido por el cliente y en ese caso puede decidir retomar la conexión con los parámetros ya negociados anteriormente (resume) o ofrecer un nuevo id obligando a realizar de nuevo un handshake completo. Como se puede entender, es un método que conviene usar muy repetidamente pues estamos reutilizando las misma claves de cifrado que pueden tiempo y mas oportunidad de análisis a un tercero que capture el tráfico.
La negociación y establecimiento de la conexión consta de un intercambio de varias estructuras handshake (Message Types) y que, en el caso una conexión simple (autenticación de servidor) podemos ver esquematizada en la siguiente figura:
Fig 1. SSL/TLS Handshake
Detalle de un Handshake simple
- Client Hello. El cliente envía un mensaje ClientHello al servidor especificando una lista de conjunto de cifrados (Cipher Suites), métodos de compresión (Compression Methods) 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 un identificador no nulo de la sesión si quiere intentar "retomar" una sesión establecida con anterioridad. Si el Id es nulo se renegocia handshake completo.
- Server Hello. El servidor contesta al cliente escogiendo una suite de las ofrecidas, enviando id de sesión, versión, compresión y un numero aleatorio (Random) que se usará con el de cliente en la creación de la clave simétrica.
- Certificate. Ofrece su certificado. Este puede contener clave pública para el cifrado o ser un certificado de firma con lo será necesario el paso 4 para enviar una clave pública firmada.
- ServerKeyExchange. Este mensaje se envía sólo si el anterior mensaje no incluye clave pública para el cifrado escogido. Con este mensaje el servidor ofrece para el cifrado asimétrico entre cliente y servidor la clave pública firmada con la clave del Certificado . De esta forma se separa la autenticación (paso 3 , certificate) del cifrado. Lo más común es que el Certificado sea un certificado de autenticación de servidor que incluya la clave pública de cifrado
- Server Hello Done. El server da por concluida su fase de negociación asimétrica.
- ClientKeyExchange. El cliente tras haber comprobado y validado el certificado, genera el premaster secret (48 bytes, 2 bytes de la versión SSL y 46 aleatorios) que será el elemento secreto compartido que junto a otros datos intercambiados previamente (random, id de servidor y cliente) daran lugar a un mismo master secret en la parte servidor y en la cliente y que será la clave simétrica utilizada para cifrar los datos. El premaster secret es cifrado con la clave pública del servidor y enviada. De este modo sabemos que solo el servidor legítimo puede descifrarlo y generar el master secret de la sesión.
- ChangeCipherSpec. Con este mensaje el cliente informa que los sucesivos estarán cifrados con el cifrado acordado.
- Finished. El cliente da por finalizada su handshake. El mensaje que finaliza el Handshake incluye un hash de todos los mensajes de handshake que garantiza la integridad de la comunicación.
- ChangeCipherSpec. El servidor tras checkear que todo ha ido correctamente (en base al hashing MAC) , descifra con su clave ptrivada el premaster secret enviado por el cliente en el paso 6 y genera el master secret del mismo modo que el cliente. En este momento cliente y servidor han logrado establecer una clave simétrica y acordado un cifrado. Con este mensaje el servidor indica que sus mensajes desde este momento se cifran.
- Finished. Parte servidor finaliza el handshake....
El canal SSL está creado, todos los datos serán cifrados. Tiempo para el Application Protocol. Empieza la fiesta privada!!!
Handshake Abreviado
Esta tabla muestra los diferentes mensajes en la conexión abreviada. Cada link lo llevará a la explicación del mensaje.| Cliente | Server |
|---|---|
| ClientHello | |
| ServerHello | |
| ChangeCipherSpec | |
| Finished | |
| ChangeCipherSpec | |
| Finished | |
| Datos de Aplicación <-----> | <-----> Datos de Aplicación |
En una forma resumida, el handshake es como sigue:
El cliente envía un ClientHello usando el session-ID de la sesión a ser reanudada y otros 48 bytes random. El server luego chequea en su cache de sesiones para ver si encuentra esa sesión. Si se encuentra la sesión, y el server está dispuesto a reestablecer la conexión bajo el estado especificado de sesión, mandará un ServerHello con el mismo valor de session-ID y otros 48 bytes random. Se debe regenerar el master secret y las claves de sesión, los secretos MAC y los IVs. En este punto tanto el cliente como el server deben enviar directamente mensajes ChangeCipherSpec y Finished. Una vez que el reestablecimiento esta completo, el cliente y server empiezan a intercambiar datos de aplicación.
Si el server no puede encontrar el session-ID en su cache, el server genera una nuevo session-ID y tanto el cliente como el server TLS ejecutan un handshake completo.
No hay comentarios:
Publicar un comentario