TLS

El protocolo TLS (Transport Layer Security) es una evolución del protocolo SSL (Secure Sockets Layer), es un protocolo mediante el cual se establece una conexión segura por medio de un canal cifrado entre el cliente y servidor. Así el intercambio de información se realiza en un entorno seguro y libre de ataques. La última propuesta de estándar está documentada en la referencia RFC 2246.

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.

DESCRIPCIÓN DEL PROTOCOLO

El protocolo SSL/TSL se basa en tres fases básicas:

  • Negociación: Los dos extremos de la comunicación (cliente y servidor) negocian 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).
-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.
  • Transmisión Segura: los extremos pueden iniciar el tráfico de información cifrada y autentica.

OBJETIVOS DEL PROTOCOLO TLS

Los objetivos del protocolo son varios:

  • Seguridad criptográfica. El protocolo se debe emplear para establecer una conexión segura entre dos partes.
  • Interoperabilidad. Aplicaciones distintas deben poder intercambiar parámetros criptográficos sin necesidad de que ninguna de las dos conozca el código de la otra.
  • Extensibilidad. El protocolo permite la incorporación de nuevos algoritmos criptográficos.
  • Eficiencia. Los algoritmos criptográficos son costosos computacionalmente, por lo que el protocolo incluye un esquema de cache de sesiones para reducir el número de sesiones que deben inicializarse desde cero (usando criptografía de clave pública).

FUNCIONAMIENTO DEL PROTOCOLO TLS

El protocolo está dividido en dos niveles:

  • Protocolo de registro TLS (TLS Record Protocol).
  • Protocolo de mutuo acuerdo TLS (TLS Handshake Protocol).

El de más bajo nivel es el Protocolo de Registro, que se implementa sobre un protocolo de transporte fiable como el TCP. El protocolo proporciona seguridad en la conexión con dos propiedades fundamentales:

  • La conexión es privada. Para encriptar los datos se usan algoritmos de cifrado simétrico. Las claves se generan para cada conexión y se basan en un secreto negociado por otro protocolo (como el de mutuo acuerdo). El protocolo también se puede usar sin encriptación.
  • La conexión es fiable. El transporte de mensajes incluye una verificación de integridad.

El Protocolo de mutuo acuerdo, proporciona seguridad en la conexión con tres propiedades básicas:

  • La identidad del interlocutor puede ser autentificada usando criptografía de clave pública. Esta autentificación puede ser opcional, pero generalmente es necesaria al menos para uno de los interlocutores.
  • La negociación de un secreto compartido es segura.
  • La negociación es fiable, nadie puede modificar la negociación sin ser detectado por los interlocutores.

Esquema de operación del protocolo de mutuo acuerdo (TLS Handshake Protocol)

Cliente. Dígame usted quién es? *Tome aquí están los certificados que yo soporto…?

Servidor. Aquí esta mi Certificado para probar mi identidad.

Cliente. Con su certificado, he verificado su identidad y tengo su llave pública.

Servidor. Aquí están y envío los protocolos que he decidido que vamos a utilizar.

Cliente. Aquí esta una llave secreta que he creado con sus protocolos y encriptado con su llave pública.

Servidor. Aquí va una copia de todo la conversación dicha, encriptada con nuestra llave secreta.

Cliente. Aquí va una copia de toda la conversación dicha, encriptada con nuestra llave secreta.

La comunicación entre los nodos CLIENTE y SERVIDOR está basada 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), enviándose 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.

  • Versión de SSL del cliente (3.2)
  • Sello de Tiempo
  • 28 bytes aleatorios
  • ID de sesión (para reabrir sesión) o vacío
  • Lista de combinaciones de algorítmos (intercambio de clave, cifrado, MAC)
  • Lista de algoritmos de comprensión (incluye null)

 

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.

Mejor versión de SSL del servidor compatible con la versión del cliente.

  • Sello de tiempo
  • 28 bytes aleatorios
  • ID de sesión
  • Combinación de algoritmos escogida
  • Algoritmos de comprensión escogido

 

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.

Server certificate (servidor al cliente)

  • Certificado X.509 del servidor
  • Certificado X.509 de la Autoridad de Certificación 1
  • Certificado X.509 de la Autoridad de Certificación 2

Server key exchange (servidor al cliente)

Parámetros para establecer el secreto común.

  • RSA: clave pública temporal para cifrar el secreto
  • Diffie-Hellman: p,g,g(x)

Firma (incluye los números aleatorios de “Client hello” y “Server hello”)


 

Si la conexión tiene que ser mutuamente certificada el servidor pide un certificado al cliente y éste se la enviaría.

Certificate Request: Pide al cliente que se autentique. (el servidor envía al cliente)


 

El cliente verifica la autenticidad del servidor.

Server hello done (el servidor envía hola)

Client certificate (el cliente envía el certificado)

  • Certificado X.509 del cliente
  • Certificado X.509 de la Autoridad de Certificación 1
  • Certificado X.509 de la Autoridad de Certificación 2

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.

Server key exchange (servidor al cliente)

Parámetros para establecer el secreto común.

  • RSA: clave pública temporal para cifrar el secreto
  • Diffie-Hellman: p,g,g(x)

Firma (incluye los números aleatorios de “Client hello” y “Server hello”)

Client key exchange (cliente responde al servidor)

Establecimiento del pre-secreto común.

  • RSA: genera 48 bytes aleatorios y la cifra con la clave RSA (temporal o permanente)
  • Diffie-Hellman: genera y manda g(y)

Certificate verify (cliente envía al servidor)

Firma de la compilación de todos los mensajes de negociación anteriores


 

Cliente y servidor aplican los parámetros negociados.

Change cipher spec (cliente al servidor)

Pide aplicar los nuevos parámetros negociados

Finished (cliente al servidor)

Primeros 12 bytes de PRF (secreto principal, “client finished”, MD5 (negociación) + SHA1 (negociación))

Change cipher spec (servidor responde al cliente)

Pide aplicar los nuevos parámetros negociados

Finished (servidor al cliente)

Primeros 12 bytes de PRF (secreto principal, “server finished”, MD5 (negociación) + SHA1 (negociación))

Vocabulario:

Diffie-Hellman: El protocolo criptográfico Diffie-Hellman, debido a Whitfield Diffie y Martin Hellman, (Diffie–Hellman Problem->DHP) es un protocolo de establecimiento de claves entre partes que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima (no autentificada).

Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión (establecer clave de sesión). Siendo no autenticado, sin embargo, provee las bases para varios protocolos autenticados.

RSA: (Rivest, Shamir y Adleman) es un sistema criptográfico de clave pública desarrollado en 1977. Es el primer y más utilizado algoritmo de este tipo y es válido tanto para cifrar como para firmar digitalmente.


APLICACIONES DEL PROTOCOLO TLS

El protocolo SSL/TLS tiene multitud de aplicaciones en uso actualmente. La mayoría de ellas son versiones seguras de programas que emplean protocolos que no lo son. Hay versiones seguras de servidores y clientes de protocolos como el http, nntp, ldap, imap, pop3, etc.

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 electronic, 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.

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.

Implementaciones del Protocolo TLS

Existen diferentes implementaciones, como por ejemplo:

  • OpenSSL: es 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, que ayuda 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).
  • GnuTLS: es una implementación de código abierto con licencia compatible con GPL.
  • JSSE: es una implementación realizada en el Java incluida en el Java Runtime Environment.

Estandares y Definiciones RFC del Protocolo TLS

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.

  • RFC 2712: Aparecen las familias de cifrados de 40 bits definidas, para advertir que ya han sido asignadas.
  • RFC 2817: Explica cómo usar el mecanismo de actualización en HTTP/1.1 para iniciar TLS sobre una conexión TCP existente, permitiendo al tráfico seguro e inseguro HTTP compartir el mismo puerto.
  • RFC 2818: Diferencia el tráfico seguro e inseguro HTTP usando un puerto de servidor diferente.
  • RFC 3268: Añade la familia de cifrado AES.
  • RFC 3546: Añade un mecanismo para negociar extensiones de protocolos durante la inicialización de sesión y define algunas extensiones.
  • RFC 4279: Añade tres conjuntos de nuevas familias de cifrados para que el protocolo TLS permita la autenticación basada en claves previamente compartidas.

VERSIONAMIENTO DEL PROTOCOLO TLS

El protocolo TLS ha evolucionado desde la versión 1.0 hasta la actual versión que es la 1.1. Esta última versión 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. En TLS 1.0 se usaba la versión 1.5 del estándar RSA para criptografía de clave pública (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.

MEDIAS DE SEGURIDAD DEL PROTOCOLO TLS

  • Numera todos los registros y usa el número de secuencia en MAC.
  • Usa un resumen de mensaje mejorado con una clave (de forma que solo con dicha clave se pueda comprobar el MAC).
  • 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 tornen vulnerables en el futuro.

APLICATIVOS

Para el funcionamiento del protocolo TLS / SSL, a continuación se determinara el aplicativo, para configurar el protocolo de seguridad en servidores Windows, Linux y mediante software; permitiendo crear certificados por el lado del servidor y cliente, realizando una conexión segura en la web.

Sistema Operativo Windows

El Terminal Server utiliza cifrado RDP nativo y no autentica el servidor, para utilizar el protocolo TLS en la autenticación de servidores y el cifrado de las comunicaciones, es preciso configurar correctamente el cliente y el servidor.

  • Deben ejecutarse en Windows Server 2003 con SP1.
  • Es preciso obtener un certificado para el servidor Terminal Server. Para ello, realizamos:
  • Abrimos el Internet Explorer, en el nos conectamos a http:///certsrv, donde se encuentra la entidad emisora de certificados (CA) a que desea tener acceso.
  • Hacer clic en solicitar un certificado.
  • Hacer clic en certificado de usuario y enviar certificado.
  • Escriba la información de su identificación para el certificado y enviar.
  • La pág. Web le mostrará un mensaje de certificado emitido, haga clic en instalar este certificado.
  • En opciones de Internet del servidor habilitar la función usar TLS 1.0

Sistema Operativo Linux

Como requisitos antes de implementar el certificado por lado del servidor se requiere disponer de una IP pública para cada sitio de la red virtual con soporte SSL/TLS.

Si se utiliza CentOS o White Box Enterprise Linux, se ejecuta el siguiente comando:

yum –y install mod_ssl

Si se utiliza Red Hat, se ejecuta el comando:

up2date –i mod_ssl

CONCLUSIONES

  • El protocolo TLS está basado en SSL y son muy similares en su forma de operar, encriptando la comunicación entre el servidor y cliente mediante el uso de algoritmos.
  • La seguridad es un aspecto fundamental para muchas aplicaciones cliente-servidor, siendo 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.
  • La aplicación y el uso del protocolo TLS junto con otras técnicas de encriptación como IPSec, cifrado RPC, etc, nos ayudan a mantener la confidencialidad e integridad de los datos durante la comunicación, protegiendo así datos confidenciales como números de tarjetas de crédito en las diferentes transacciones de comercio electrónico, 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”.
  • TLS aplica un algoritmo de hash con claves para el código de autenticación de mensajes (HMAC), mientras que SSL aplica un algoritmo de código de autenticación de mensajes (MAC).
  • HTTP no es un protocolo seguro, ya que es simple y no se establece un estado cliente/servidor. Ejecuta sobre TCP/IP. Por esta razón es necesario instrumentar medidas de seguridad mediante de la aplicación del protocolo TLS
  • HTTP, es una de las aplicaciones más comunes del protocolo TLS con la cual se genera el HTTPS. Esta implementación requiere de servidores Web y navegadores Web que soporten el protocolo TLS. Ejemplo de estos tenemos:
  • Netscape
  • Internet Explorer
  • Cryptozilla
  • Netscape Mozilla sources with SSLeay

Fuentes:

  • Wikipedia
  • http://www.monografias.com/trabajos74/protocolo-tls-transport-layer-security/protocolo-tls-transport-layer-security.shtml
Etiquetado con:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.