Informe TLS
Informe TLS
Informe TLS
Grupo de Trabajo:
Profesor:
Javier Navarro
201021056-1
Gilian Ubilla
201021013-8
Mario Tejeda
201021049-9
Agustn Gonzlez
28 de julio de 2014
Resumen
El siguiente informe trata sobre el proyecto nal correspondiente a la asignatura Redes de Computadores
I. El tema abordado es un protocolo que permite la transferencia segura de datos: Transport Layer Security
(TLS). Para comenzar se abordarn aspectos rudimentarios sobre seguridad en redes de computadoras. Luego
se har un breve paso por la evolucin del protocolo, desde sus inicios hasta llegar a lo que actualmente se
utiliza. Finalmente se explicar el funcionamiento del protocolo para luego mostrar el proceso de comunicacin
entre cliente y servidor, el cual ser contrastado con un caso prctico a travs de Wireshark.
Introduccin
A medida que las redes de computadoras comenzaron a desarrollarse, se buscaron nuevas aplicaciones para
dar uso a esta vasta herramienta y pronto fue necesario contar con servicios que permitieran dar seguridad a los
datos que eran compartidos entre hosts. El correo electrnico sirve como un claro ejemplo. Las cuentas pueden
ser utilizadas para transferir informacin de gran importancia y la escaces de seguridad puede provocar que
algn tercero mal intencionado intercepte los mensajes compartidos y lleve a cabo acciones de suplantamiento
o robo de informacin. Fue as como en 1995 la empresa de software Netscape Communications desarroll
SSL 1.0, para aplicaciones seguras en transacciones comerciales electrnicas. Las fallas encontradas en las
primeras versiones daran paso a sucesivas mejoras y a una estandarizacin como protocolo cuyo resultado se
convirti en lo que hoy es conocido como Transpor Layer Securitiy.
Cifrado y encriptacin.
Antes de adentrar a TLS, es necesario comprender ciertos aspectos bsicos en la seguridad en el proceso de
comunicacin en las redes, para ello se denen ciertos conceptos bsicos tales como llaves pblicas y privadas
y certicados digitales.
Se ha de denir la criptografa como la creacin de tcnicas para el cifrado de datos. Teniendo como objetivo
conseguir la condencialidad de los mensajes.
En criptografa, el cifrado es un procedimiento que utiliza un algoritmo de cifrado con cierta clave (clave
de cifrado) transformando un mensaje, sin atender a su estructura lingstica o signicado, de tal forma que
sea incomprensible o, al menos, difcil de comprender a toda persona que no tenga la clave secreta (clave de
descifrado) del algoritmo.
El juego de caracteres (alfabeto) usado en el mensaje sin cifrar puede no ser el mismo que el juego de
caracteres que se usa en el mensaje cifrado.
Aunque el cifrado pueda volver secreto el contenido de un documento, es necesario complementarlo con
otras tcnicas criptogrcas para poder comunicarse de manera segura. Puede ser necesario garantizar la
integridad la autenticacin de las partes.
Netscape Communications Corporation es una empresa de software famosa por ser la creadora del navegador web Netscape
Navigator.
La compaa fue fundada como Mosaic Communications Corporation el 4 de abril de 1994 por Marc Andreessen y Jim
Clark
El principal problema con los sistemas de cifrado simtrico no est ligado a su seguridad, sino al intercambio
de claves. Una vez que el remitente y el destinatario hayan intercambiado las claves pueden usarlas para
comunicarse con seguridad, pero qu canal de comunicacin que sea seguro han usado para comunicar la
clave entre ellos? Sera mucho ms fcil para un atacante intentar interceptar una clave que probar las posibles
combinaciones del espacio de claves. Otro problema es el nmero de claves que se necesitan. Si tenemos un
nmero n de personas que necesitan comunicarse entre ellos, entonces se necesitan n(n-1)/2 claves para cada
pareja de personas que tengan que comunicarse de modo privado. Esto puede funcionar con un grupo reducido
de personas, pero sera imposible llevarlo a cabo con grupos ms grandes.
Los sistemas de cifrado de clave pblica se inventaron con el n de evitar por completo el problema del
intercambio de claves. Un sistema de cifrado de clave pblica usa un par de claves para el envo de mensajes.
Las dos claves pertenecen a la misma persona a la que se ha enviado el mensaje. Una clave es pblica y se
puede entregar a cualquier persona. La otra clave es privada y el propietario debe guardarla para que nadie
tenga acceso a ella. El remitente usa la clave pblica del destinatario para cifrar el mensaje, y una vez cifrado,
slo la clave privada del destinatario podr descifrar este mensaje.
Este protocolo resuelve el problema del intercambio de claves, que es inherente a los sistemas de cifrado
simtricos. No hay necesidad de que el remitente y el destinatario tengan que ponerse de acuerdo en una
clave. Todo lo que se requiere es que, antes de iniciar la comunicacin secreta, el remitente consiga una copia
de la clave pblica del destinatario. Es ms, esa misma clave pblica puede ser usada por cualquiera que
desee comunicarse con su propietario. Por tanto, se necesitarn slo n pares de claves por cada n personas
que deseen comunicarse entre ellas.
Otra utilidad de los Certicados Digitales es que posibilitan el envo de mensajes cifrados: utilizando la
clave pblica de un Certicado, es posible cifrar un mensaje y enviarlo al titular del Certicado, quien ser
la nica persona que podr descifrar el mensaje con su clave privada.
Ya con estos conceptos es posible que el lector se sumerja en TLS y su funcionamiento.
Evolucin de TLS
SSL fue desarrollado por Netscape con el n de habilitar la posibilidad de transacciones comerciales seguras
en la web. En 1994 se consigue la versin SSL 1.0, sin embargo, esta no es liberada y solo circula a nivel
interno de la empresa debido a deciencias importantes en sus servicios, como no entregar proteccin de
integridad en los datos y no utilizar nmero de secuencia durante un intercambio lo que permita realizar
ataques de replicacin.
En 1995 luego de corregir algunas fallas, se entrega SSL 2.0. A pesar de estas mejoras, aun hay fallas
importantes que provocan que sea considerado un protocolo desaprobado para su uso en aplicaciones de
seguridad. Una falla importa se presentan durante la etapa de Handshake, en la cual no se aplica cifrado por
lo que un atacante puede engaar al usuario para que se elija un mtodo de cifrado poco efectivo.
En 1996 se entrega SSL 3.0 como un rediseo completo del protocolo. Esta versin aade mejores opciones
de cifrado y habilita la autenticacin de certicados. Las mejoras en seguridad permiten que se considere
como un protocolo aprobado en aplicaciones de seguridad.
En 1999, tras un esfuerzo por la IETF, se estandariz el protocolo resultando el RFC 2264 el cual pas
a ser conocido como TLS 1.0, una actualizacin de SSL 3.0 (aveces mencionado como SSL 3.1). Si bien los
cambios no son excesivos se especica que hay problemas de compatibilidad entre TLS 1.0 y SSL 3.0, pero
que el protocolo implementa un modo de operacin que al restar servicios de seguridad lo permite.
En 2006 y 2008 se presentan TLS 1.1 y TLS 1.2 respectivamente para aadir mejoras de seguridad en
consecuencia de fallas detectadas y mejoras en los distintos tipos de ataque. Actualmente TLS 1.2 es el
protocolo por defecto en gran parte de los buscadores ms utilizados. La gura 2 muestra el soporte de TLS
en algunos navegadores.
Funcionamiento de TLS
El protocolo TLS tiene multitud de aplicaciones en uso actualmente. La mayora de ellas son versiones
seguras de programas que emplean protocolos que no lo son. Hay versiones seguras de servidores y clientes
de protocolos como HTTP, SMTP, IMAP y POP3.
El protocolo TLS se ejecuta en una capa entre los protocolos de aplicacin como: HTTP sobre SSL/TLS es
HTTPS, ofreciendo seguridad a pginas web para aplicaciones de comercio electronico, utilizando certicados
de clave pblica para vericar la identidad de los extremos. Visa, MasterCard, American Express y muchas
de las principales instituciones nancieras han aprobado SSL para el comercio sobre Internet. SSH utiliza
TLS por debajo. SMTP y NNTP pueden operar tambin de manera segura sobre TLS. POP3 e IMAP4 sobre
TLS son POP3S e IMAPS. TLS tambin puede ser usado para tunelizar una red completa y crear una red
privada virtual (VPN), como en el caso de OpenVPN [1].
Adems, el protocolo se subdivide en 2 capas (o protocolos) principales, la capa Handshake TLS y la capa
de registro TLS. La capa handshake se ubica entre la capa de registro y la aplicacin y es encargada de
generar mensajes correspondientes a cada situacin. La capa de registro se ubica sobre la capa de transporte
y recibe los mensajes desde la capa de Handshake y los acondiciona para ser enviados.
Client Hello:
El cliente enva un mensaje al servidor para dar inicio a una conexin cifrada, especicando
una lista de conjuntos de cifrados, mtodos de compresin soportados, la versin del protocolo SSL/TSL
ms baja permitida y la versin SSL/TLS ms alta soportada. Adems, se enva una cadena de 32 bytes
aleatorios que sirven para generar la clave simtrica (ms adelante en el protocolo). Tambin, se incluye
un identicador de sesin (ID), en caso de intentar "retomar" una sesin establecida con anterioridad
y hacer un handshaking ms corto
Server Hello:
la versin de TLS a utilizar en la conexin, el tipo de compresin de datos y otra cadena de 32 bytes
aleatorios
Certicate:
Con este mensaje el servidor ofrece para el cifrado asimtrico entre cliente y servidor
(48 bytes) cifrado con la clave pblica del servidor y se lo enva. Luego, cliente y servidor pueden generar
el master secret aplicando funciones hash a la cadena random de 32 bytes y al premaster secret, usado
para el cifrado simtrico de datos.
Con este mensaje el cliente informa que sus mensajes sucesivos estarn cifrados con
Finished:
El cliente da por nalizada su fase de negociacin asimtrica. El mensaje que naliza el handshake
incluye un hash de todos los mensajes de handshake que garantiza la integridad de la comunicacin.
El servidor descifra con su clave privada el premaster secret enviado por el cliente y
genera por su cuenta el master secret. Desde este momento, cliente y servidor han logrado establecer
una clave simtrica. Con este mensaje el servidor indica que sus mensajes desde este momento sern
cifrados simtricamente.
Finished:
haciendo un hash a todos los mensajes concatenados anteriores. Con este protocolo de negociacin
nalizado, se logra crear un canal bajo el protocolo TLS que garantiza que todos los datos enviados por
el protocolo de aplicacin sern cifrados
A continuacion, se muestra la captura de paquetes de una sesin TLS usando Wireshark, para visualizar
el envo de paquetes en una negociacin. En particular, se usa el protocolo HTTPS para la conexin a
www.google.cl; en donde el browser Google Chrome usa la versin TLS 1.2 por defecto .
Como se observa de la gura 3, la conexin abre un puerto con conexin segura (51148) y algunos pasos de
la negociacin se encapsulan en un solo paquete, dada su poca longitud. Luego de la negociacin, se empieza
la conexin mediante el canal TLS con el paso de los datos por medio de TCP. El paquete Certicate de parte
del servidor, aparte del envo de su certicado , tambin enva los mensajes de tipo Server Key Exchange y
Server Hello Done
El registro genrico de protocolo TLS (gura 5)dene los 4 posibles valores en el campo content_type.
El tipo Handshake (content_type=22) es el que se usa en el establecimiento de la conexin cliente-servidor;
cada paso del handshaking tiene un nombre asociado y a su vez un valor en el campo Message type. El tipo
ChangeCipherSpec (content_type=20) es enviado por el cliente y servidor para noticar que los siguientes
registros estarn protegidos bajo un nuevo tipo de cifrado. El tipo Alert (content_type=21) es para manejo
de errores, los cuales pueden ser un mensaje de aviso, para el n normal de la conexin, o un error fatal .
Un error fatal provoca el n de la conexin de manera abrupta y la invalidacin del identicador de sesin;
son ejemplos de errores fatales un MAC incorrecto, tipo de mensaje inesperado, error de negociacin, etc.
El tipo Application (content_type =23) contiene los datos cifrados de la aplicacin, llevndolos a la capa de
transporte. El campo Version especica la versin del protocolo que se utiliza. El campo Length, el largo del
mensaje. El campo Payload contiene el mensaje enviado por el protocolo correspondiente. El campo MAC
se utiliza para llevar a cabo un seguimiento de la conversacin entre cliente y servidor con el n de evitar la
intervencin de terceros. El campo Padding solo contiene data cifrada, la cual puede corresponder a datos
cifrados de la capa de aplicacin.
Conclusiones y Comentarios
Se concluye que TLS es un protocolo de gran importancia para muchas aplicaciones en la red. Es un
estndar en comunicacin segura y los navegadores y servidores lo utilizan por defecto.
Gracias a los servicios que proporciona los terminales en una red pueden autenticarse sin tener contacto directo
y llevar a cabo operaciones de extrema importancia (como el pago de arancel universitario) sin temor a que
terceros hagan mal uso de la informacin intercambiada (i.e. informacin de cuenta bancaria). Finalmente,
si bien el protocolo busca proporcionar seguridad, siempre ser posible romperla, sin embargo, las continuas
mejoras que se han realizado permiten convertir esto en una tarea difcil.
Referencias
[1] http://deic.uab.es/material/26118-ssl.pdf. Proteccin de nivel de transporte: SSL/TLS/WTLS.
[2] http://lobobinario.blogspot.com/2011/02/analizando-ssl-ii-de-iii-aplicaciones-y.html. Analizando SSL ( II
de III): Aplicaciones y Estructura
[3] http://tools.ietf.org/html/rfc5246#section-4.RFC 5246. The Transport Layer Security (TLS) Protocol
Version 1.2
[4] http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#_testing_and_verication.
Chapter
[5] http://portalae.sci.uma.es:8080/export/sites/default/uma/documentos/criptograa_certicado_digital_rma_d
Anexos
(a) ClientHello
(b) ServerHello
El servidor prosigue con el protocolo enviando su certicado de autenticidad , el envo de su clave pblica
y la nalizacin por parte suya del protocolo, con un Server Hello Done de 4 byte de longitud. Los valores de
tipo de mensaje que identican esta secuencia son 11, 12 y 14 respectivamente
En la gura 9 se observa por parte del cliente y servidor el intercambio de claves, con lo cual se pasa de
un cifrado asimtrico a simtrico de datos. Notar que este cambio se identica con el mensaje Change Cipher
Spec de apenas 1 byte de longitud. El mensaje New Session Ticket es una extensin de TLS que le permite
al cliente volver a iniciar una conexin TLS sin necesidad de rehacer el handshake completo nuevamente, con
ello el servidor guarda una copia del estado de la sesin TLS en proxy