Transmissió de Dades
1. INTRODUCCIÓN.
TLS (Transport Layer Security - Seguridad de la Capa de Transporte) es el sucesor del SSL (Secure Sockets Layer). Ambos protocolos sirven para proporcionar comunicaciones seguras en Internet, usando un modelo de autenticación y privacidad de la información entre extremos sobre Internet mediante criptografía. Esto es fundamental para mantener la seguridad en el comercio vía Internet.
SSL fue diseñado de manera modular (extensible), con soporte para compatibilidad hacia delante y hacia atrás y negociación entre las partes (peer-to-peer).
Normalmente el servidor es el único que es autenticado, garantizando así su identidad, pero el cliente se mantiene sin autenticar, ya que para la autenticación mútua se necesita una infraestructura de claves públicas (o PKI) para los clientes.
Estos protocolos permiten prevenir escuchas (eavesdropping), evitar la falsificación de la identidad del remitente y mantener la integridad del mensaje en una aplicación cliente-servidor.
La versión 3.0 del SSL fué desarrollada por Netscape en 1996, que fué la base para desarrollar la verxión 1.0 del TLS, protocolo estándar IETF definido en el RFC 2246 por primera vez.
Las primeras implementaciones de SSL sólo podían usar claves simétricas de 40 bits como máximo, ya que el gobierno de los EEUU imponía restricciones sobre la exportación de tecnología criptográfica. Esta clave era de 40 bits ya que las agencias de seguridad nacional americanas podían atacrla mediante fuerza bruta y poder leer así el tráfico cifrado, mientras que los posibles atacantes con menores recursos no podrían leerlo. Finalmente, después de diferentes juicios y la aparición de mejores productos criptográficos diseñados en otros países, se rebajaron las restricciones de exportación de tecnología criptográfica, desapareciendo casi por completo la limitación de claves de 40 bits. Actualmente se usan claves de 128 bits, o incluso más, para las claves de cifrado simétricas.
2. DESCRIPCIÓN.
El protocolo SSL/TSL se basa en tres fases básicas:
NEGOCIACIÓN: los dos extremos de la comunicación (cliente y servidor) negocián que algoritmos criptográficos utilizarán para autenticarse y cifrar la información. Actualmente existen diferentes 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 o AES (Advanced Encryption Standard).
Con funciones hash: MD5 o de la familia SHA.
AUTENTICACIÓN Y CLAVES: los extremos se autentican mediante certificados digitales e intercambian las claves para el cifrado, según la negociación anterior.
TRANSMISIÓN SEGURA: los extremos pueden iniciar el tráfico de información cifrada y autentica.
2.1. FUNCIONAMIENTO.
El protocolo SSL/TSL está basado en el intercambio de mensajes. En cada mensaje existe un campo (content_type) donde se especifica el protocolo de nivel superior utilizado. Estos mensajes puede ser comprimidos, cifrados y empaquetados con un código de autentificación del mensaje (MAC)
En el inicio de un conexión el nivel de mensaje encapsula un protocolo handshake (content_type=22), envíandose diferentes mensajes:
El cliente inicia la comunicación enviando un mensaje "Client Hello" dónde especifica una lista de conjunto de cifrados, métodos de compresión y la versión del protocolo SSL más alta permitida. A la vez envía una serie de bytes aleatorios (Challenge de Cliente o Reto) que después serán usados. Adicionalmente puede enviar el identificador de la sesión.
El servidor responde con un mensaje "Server Hello" donde se indican los parámetros elegidos por el servidor a partir de las opciones ofertadas por el cliente.
Una vez establecidos los parámetros de la conexión, cliente y servidor intercambian los certificados, según las claves públicas de cifrado seleccionadas. Actualmente son certificados X.509, pero existe un borrador en el que se especifica el uso de certificados basados en OpenPGP.
Si la conexión tiene que ser mútuamente certificada el servidor pide un certificado al cliente y éste se la enviaría.
- El cliente verifica la autenticidad del servidor.
Cliente y servidor negocian una clave secreta común (master secret), que puede derivarse de un intercambio Diffie-Hellman, o utilizando la clave privada de cada uno para cifrar una clave pública que servirá para cifrar a la vez la clave secreta. El resto de claves son derivadas 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 pseudo-aleatoria.
Cliente y servidor aplican los parámetros negociados.
2.2. MEDIDAS DE SEGURIDAD.
Existen diferentes medidas de seguridad aplicables:
Numerar todos los mensajes usando el número de secuencia en el MAC.
Usar un resumen de mensaje mejorado con una clave, para que únicamente con esa clave se pueda comprobar el MAC (especificado en el RFC 2104).
Protección contra ataques conocidos (incluídos man in the middle attack), que impliquen un degradado del protocolo a versiones anteriores menos seguras, o a cifrados más débiles.
Envío de un hash de todos los datos intercambiados en el mensaje que finaliza el handshake (Finished).
La función pseudo-aleatoria divide en dos partes los datos de entrada y las procesa con diferentes algoritmos hash (MD5 y SHA), después hace una XOR sobre ellos. Evitando una posible vulnerabilidad futura de estos algoritmos.
3. EJEMPLOS.
3.1. APLICACIONES.
El protocolo SSL/TLS se ejecuta en una capa entre los protocolos de aplicación como:
HTTP sobre SSL/TLS es HTTPS, ofreciendo seguridad a páginas WWW para aplicaciones de comercio electrónico.
utilizando certificados de clave pública para verificar la identidad de los extremos. Visa, ?MasterCard, American Express y muchas de las principales instituciones financieras han aprobado SSL para el comercio sobre Internet.
SSH utiliza SSL/TLS por debajo.
SMTP y NNTP pueden operar también de manera segura sobre SSL/TLS.
POP3 i IMAP4 sobre SSL/TLS son POP3S i IMAPS.
También se puede ejecutar sobre el protocolo de transporte TCP, que forma parte de la familia de protocolos TCP/IP.
Existen múltiples productos clientes y servidores que pueden proporcionar SSL de forma nativa, pero también existen muchos que aún no lo permiten. una solución podría ser usar una aplicación SSL independiente como Stunnel para conseguir el cifrado, pero IETF recomendó en 1997 que los protocolos de aplicación ofrecieran una forma de actualizar a TLS a partir de una conexión sin cifrado (plaintext) en vez de usar un puerto diferente para cifrar las comunicaciones, evitando el uso de envolturas (wrappers) como Stunnel.
SSL también puede ser usado para tunelar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN.
3.2. IMPLEMENTACIONES.
Existen diferentes implementaciones, como por ejemplo:
OpenSSL: una implementación de código abierto, la más utilizada. Es un proyecto desarrollado por la comunidad Open Source para libre descarga y está basado en SSLeay desarrollado por Eric Young y Tim Hudson. Ayudan al sistema a implementar el SSL/TLS ofreciéndole un robusto paquete de herramientas de administración y librerías de criptografía que pueden ser usadas para OpenSSH y navegadores web (acceso seguro a HTTPS). Es muy útil para requerimientos de ciertos niveles de seguridad en Linux. También permite la creación de certificados digitales aplicables a nuestro servidor, por ejemplo Apache.
GnuTLS: una implementación de código abierto con licencia compatible con GPL.
JSSE: una implementación realizada en el Java incluida en el Java Runtime Environment.
3.3. ESTÁNDARES.
La primera definición de TLS apareció en el RFC 2246: "The TLS Protocol Version 1.0" (El protocolo TLS versión 1.0) y está basada en la versión 3.0 de SSL, siendo prácticamente equivalentes.
Posteriormente se extendió dicha definición:
RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". Aparecen las familias de cifrados de 40 bits definidas, para advertir que ya han sido asignadas.
RFC 2817: "Upgrading to TLS Within HTTP/1.1". Explica cómo usar el mecanismo de actualización en HTTP/1.1 para iniciar TLS sobre una conexión TCP existente, permitiéndo al tráfico seguro e inseguro HTTP compartir el mismo puerto.
RFC 2818: "HTTP Over TLS". Diferencia el tráfico seguro e inseguro HTTP usando un puerto de servidor diferente.
RFC 3268: "AES Ciphersuites for TLS". Añade la familia de cifrado AES.
RFC 3546: "Transport Layer Security (TLS) Extensions". Añade un mecanismo para negociar extensiones de protocolos durante la inicialización de sesión y define algunas extensiones.
RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)". Añade tres conjuntos de nuevas familias de cifrados para que el protocolo TLS permita la autenticación basada en claves previamente compartidas.
3.4. TLS 1.1.
Es la última versión aprobada del protocolo TLS. Es muy parecida a la versión anterior (TLS 1.0), pero la principal diferencia es la modificación del formato para cifrado RSA anterior al uso de 'master secret', que es parte del mensaje de intercambio de claves del cliente (si se usa RSA). En TLS 1.0 se usaba la versión 1.5 de PCK#1, pasando a usar ahora la versión 2.1. Con este cambio se consigue protección ante ataques descubiertos por Daniel Bleichenbacher que podían lanzarse contra servidores TLS 1.0, usando PKCS#1 versión 1.5. También se incluyen recomendaciones para evitar ataques remotos programados. TLS 1.1 está actualmente implementado en el navegador Opera y en GnuTLS.
4. CONCLUSIONES.
La seguridad es un aspecto fundamental para muchas aplicaciones cliente-servidor, siéndo un ejemplo muy importante, por su gran proyección en los últimos tiempos, el negocio electrónico.
Mediante el uso de SSL/TLS se ha conseguido aumentar el grado de seguridad en dichas conexiones cliente-servidor, teniendo presente que la idea de "seguridad total" es una utopía.
Como se ha explicado en esta ampliación el uso de SSL/TLS junto con otras técnicas como IPSec, cifrado RPC, etc, nos ayudan a mantener la confidencialidad e integridad de los datos durante la comunicación, protegiéndo así datos confidenciales como números de tarjetas de crédito en las diferentes transacciones de comercio electronico, envío de información privada, en una intranet o a través de Internet, de una organización, etc.
Aunque no hay que olvidar que los ataques pueden ser múltiples y cada vez más sofisticados, lo que obliga a una permanente investigación de mejora de los diferentes protocolos de seguridad, se puede decir que un uso correcto de estos protocolos nos proporciona hoy en día un nivel de seguridad "bastante aceptable".
5. FUENTES.
http://es.wikipedia.org/wiki/Transport_Layer_Security
http://leibniz.iimas.unam.mx/~yann/Crypto/Clase08.pdf
http://www.ietf.org/rfc/rfc2246.txt
http://www.ietf.org/rfc/rfc2104.txt
http://www.ietf.org/rfc/rfc2712.txt
http://www.ietf.org/rfc/rfc2817.txt
http://www.ietf.org/rfc/rfc2818.txt
http://www.ietf.org/rfc/rfc3268.txt
http://www.ietf.org/rfc/rfc3546.txt
http://www.ietf.org/rfc/rfc4279.txt
Apuntes de clase.