UNIVERSIDAD TCNICA PARTICULAR DE LOJA

La Universidad Catlica de Loja ESCUELA DE ELECTRNICA Y TELECOMUNICACIONES

SEGURIDAD DE REDES

Por: - Alexander P. Scola C. - Pablo F. Solano Fecha: 12/06/2013 Paralelo: 8vo B

MANEJO DE MENSAJES CON SSL

Para el manejo de mensajes con SSL (Secure Sockets Layer), escogimos la pgina de Banca Electrnica del Banco Pichincha la misma que cuenta con una conexin segura como podemos observar en la siguiente imagen:

Figura 1. Pgina web de la Banca Electrnica del Banco Pichincha

Para captar la informacin que est enviando y recibiendo de esta pgina se hizo uso del software Wireshark, en el mismo que podremos observar las fases de negociacin del protocolo de seguridad SSL y de acuerdo a los requerimientos de la prctica se procede a ir cumpliendo cada uno de los pasos planteados.

1. El cliente le enva al server el nmero de versin de TLS (o bien de SSL), los cipher que quiere usar, datos generados aleatoriamente, y otros tipos de informacin que el server necesita para comunicarse con el cliente usando TLS.

Figura 2. Cliente Hello

Como se puede observar en la figura el cliente para iniciar la conexin enva un mensaje al servidor el cual es Cliente Hello, que tiene diferentes caractersticas como: Versin del Protocolo Nmero aleatorio Identificador de sesin Algoritmo de compresin

Versin del Protocolo Nmero Aleatorio Identificador de sesin

Algoritmo de Compresin
Figura 3. Caractersticas de Cliente Hello

Analizando la grfica obtenida con wireshark se puede visualizar la versin del protocolo siendo este el utilizado por el cliente para la conexin en nuestro caso es el TLS 1.0 (0x0301), as mismo podemos apreciar una cadena de 32 bytes aleatorios que se envan en los mensajes de saludo, los 4 primeros deben ser una marca de tiempo, con precisin de segundos. Tambin se considera el identificador se sesin que es generado aleatoriamente en el servidor, y que permite la reutilizacin de la sesin en caso de que el cliente lo especifique que en esta sesin es nula ya que no se ha utilizado antes esta pgina y otro punto que se conoce es el algoritmo de compresin que indica el mtodo empleado para comprimir los mensajes, el nico algoritmo de compresin previsto en SSL/TLS es el algoritmo nulo, es decir, sin compresin.

2. El server le enva al cliente el nmero de versin del TLS (o SSL) del server, los cipher que quiere usar, datos generados aleatoriamente, y otros tipos de informacin que el cliente necesita para comunicarse con el server va TLS. El server tambin manda su propio certificado y, si el server est prestando un servicio que requiera autenticacin del cliente, le pide (al cliente) su certificado.

Figura 4. Server Hello

Como respuesta, el servidor enva un mensaje Server Hello, que contiene esta informacin: Versin del Protocolo Nmero aleatorio Identificador de sesin Conjunto de algoritmos de cifrado Algoritmos de Compresin

Versin del Protocolo

Nmero Aleatorio Identificador de sesin Conjunto de algoritmos de cifrado Algoritmo de Compresin

Figura 5. Caractersticas del Server Hello

El mensaje Server Hello contiene la versin del protocolo que se usar en la conexin, la versin es igual a la que envi el cliente TLS 1.0 (0x0301), en el identificador de sesin si el cliente envi uno y el servidor quiere reprender la sesin correspondiente, debe responder con el mismo identificador, si el servidor no quiere reprender la sesin el identificador enviado ser diferente. Opcionalmente, el servidor puede no enviar ningn identificador para indicar que la sesin actual nunca no podr ser respondida, as mismo el conjunto de algoritmo de cifrado si se reemplaza una sesin anterior este conjunto debe ser el mismo que se utiliz, finalmente el algoritmo de compresin escogido por el servidor o el que se escogi en la sesin que se reprende en el caso de la presente prctica es el mismo algoritmo de cliente es decir nulo.

3. El servidor debe enviar un certificado siempre que est de acuerdo en que el mtodo de intercambio de clave no es uno annimo. Este mensaje siempre requiere que inmediatamente siga el mensaje Server Hello. El tipo del certificado debe ser apropiado para el algoritmo de intercambio de clave del cipher suite seleccionado, y generalmente es un certificado X.509v3. Debe contener una clave que empareje el mtodo de intercambio. A menos que otra parte lo especifique, el algoritmo de firma para el certificado debe ser el mismo que el algoritmo para la clave del certificado. A menos que otra parte lo especifique, la clave pblica puede ser de cualquier longitud.

Figura 6. Certificado del Server Hello

Si el servidor puede autenticarse frente al cliente, que es el caso ms habitual, enva el mensaje Certicate. Este mensaje normalmente contendr el certicado del servidor, o una cadena de certicados.

Si el servidor no tiene certicado, o se ha acordado un mtodo de intercambio de claves que no precisa de l, debe mandar un mensaje Server Key Exchange, que contiene los parmetros necesarios para el mtodo a seguir.

Versin del Protocolo Nombre de la entidad a la que se emiti el certificado

Clave pblica del certificado

Figura 7. Caractersticas del certificado del Server Hello

La versin del protocolo es la misma como se puede observar tanto en el Client Hello, Server Hello y en la figura anterior del certificado que es TLS 1.0 (0x0301), adems tambin contiene en este certificado el nombre de la entidad a la cual estamos capturando el trfico, en nuestro caso el Banco Pichicha que utiliza diferentes trminos de uso y utilizando la clave pblica para este caso hace uso del algoritmo de clave RSA, as el certificado debe autorizar la clave que se usar para la encriptacin.

Figura 8. Caractersticas de finalizacin del certificado del Server Hello

Este mensaje es enviado por el server para indicar la finalizacin de los mensajes ServerHello y sus asociados. Despes de enviarlo el server esperar una respuesta del cliente. No es un mensaje opcional. Se enva para significar que el server a terminado con los mensajes para soportar el intercambio de claves, y que el cliente puede proceder con su parte. Luego de recibir el ServerHelloDone, el cliente debera verificar la condicin de que el server requiera un certificado vlido y chequear que los parmetros del mensaje sean aceptables.

4. Usando todos los datos generados en el handshake hasta ahora, el cliente (con la cooperacin del server, y dependiendo del cipher siendo usado) crea el premaster secret para esta sesin, lo encripta con la clave pblica del server (la cual se obtuvo del certificado del server que ste mand en el Paso 2), y enva el premaster secret encriptado hacia el server.

Figura 9. Cliente key Exchange

Versin del Procotolo

Cipher del Client Key Fin de mensaje Client Key

Figura 10. Caractersticas del Cliente key Exchange

El cliente enva un mensaje ClientKeyExchange, el contenido del cual depende de intercambio de claves acordado, en el caso de seguir el mtodo de RSA, en este mensaje hay una cadena de 48bytes que se usar como secreto pre-maestro, cifrado con la clave pblica del servidor, entonces el cliente y servidor calculan el secreto maestro, que ser otra cadena de 48bytes. Para realizar este clculo, se aplican funciones hash al secreto pre-maestro y a las cadenas aleatorias que se enviaron en el mensaje de saludo, a partir del secreto maestro y las cadenas aleatorias se obtiene las dos claves para el cifrado simtrico de los datos, las dos claves Mac. Este mensaje ClientKeyExchange, es enviado por el cliente y contiene el PreMasterSecret encriptado por la clave pblica del servidor y que se usar finalmente para la encriptacin y clculo de la Mac.

5. Ambas partes (cliente y server) usan el master secret para generar session keys (las claves de la sesin), las cuales son claves simtricas usadas para encriptar y desencriptar la informacin intercambiada durante la sesin TLS y para verificar su integridad (esto es, detectar cambios en los datos mientras stos viajaban por la red, antes de ser recibidos por la conexin TLS).

Versin del Procotolo

Mensaje encriptado de finalizacin

Figura 11. Caractersticas de Change Cipher Spec

Este protocolo consiste en un simple mensaje, que es encriptado y comprimido bajo el estado de conexin corriente (no pendiente). El mensaje consiste en un solo byte con valor 1. El mensaje Change Cipher Spec es enviado por ambos, el cliente y servidor para notificar la poltica (party) de recepcin de los subsiguientes registros los cuales estarn protegidos bajo la nueva negociacin del ChiperSpec y las claves. El mensaje Change Cipher Spec es enviado durante el Handshake despus que los parmetros de seguridad hayan sido agregados, pero antes el mensaje finished verificador es enviado.

El mensaje Finished sigue inmediatamente la noticacin de cambio de cifrado. Su contenido se obtiene aplicando funciones hash al secreto maestro y a la concatenacin de todos los mensajes de negociacin intercambiados, desde el Client Hello hasta el anterior a este (incluyendo el mensaje Finished de la otra parte, si ya lo ha enviado). Normalmente ser el cliente el primer en enviar el mensaje Finished, pero en el caso de reemprender una sesin anterior, ser el servidor quien lo enviar primero, justo despus del Server Hello. El contenido del mensajeFinished sirve para vericar que la negociacin se ha llevado a cabo correctamente. Este mensaje tambin permite autenticar el servidor frente al cliente, ya que el primer necesita su clave privada para descifrar el mensajeClient Key Exchange y obtener las claves que se usarn en la comunicacin.

Una vez enviado el mensaje Finished, se da por acabada la negociacin, y cliente y servidor pueden empezar a enviar los datos de aplicacin utilizando los algoritmos y claves acordados.

Conclusiones La encriptacin nos permite convertir un texto normal codificado de forma que las personas que conozcan el cdigo sean incapaces de leerlo, esto permite una mayor seguridad para enviar datos de forma confidencial a travs del internet. La herramienta wireshark nos permite conocer el trfico que est cursando a travs de la red siendo un analizador de protocolos utilizado para realizar anlisis y solucionar problemas en redes de comunicaciones. El protocolo SSL nos proporciona integridad privacidad entre dos aplicaciones de comunicaciones utilizando HTTP que es un protocolo de transporte confiable y es usado para encapsular varios tipos de protocolos de mayor nivel. El certificado que se enva desde el servidor hacia el cliente para verificar la conexin en nuestro caso lo hace a travs del algoritmo de encriptacin RSA, en el cul se enviar la clave pblica que se verificar en el cliente con el PreMasterSecret, para completar la conexin. Las versiones de los diferentes protocolos es la misma, para que se puedan comunicar las diferentes partes del protocolo SSL y no exista una prdida de datos o se pierda la conexin ya que esta es una transmisin segura.