Ssl Practica

13
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja ESCUELA DE ELECTRÒNICA Y TELECOMUNICACIONES SEGURIDAD DE REDES Por: - Alexander P. Sócola C. - Pablo F. Solano Fecha: 12/06/2013 Paralelo: 8 vo “B” MANEJO DE MENSAJES CON SSL Para el manejo de mensajes con SSL (Secure Sockets Layer), escogimos la página de “Banca Electrónica” del Banco Pichincha la misma que cuenta con una conexión segura como podemos observar en la siguiente imagen:

Transcript of Ssl Practica

Page 1: Ssl Practica

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

ESCUELA DE ELECTRÒNICA Y TELECOMUNICACIONES

SEGURIDAD DE REDES

Por: - Alexander P. Sócola 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 página de “Banca Electrónica” del Banco Pichincha la misma que cuenta con una conexión segura como podemos observar en la siguiente imagen:

Figura 1. Página web de la Banca Electrónica del Banco Pichincha

Page 2: Ssl Practica

Para captar la información que está enviando y recibiendo de esta página se hizo uso del software Wireshark, en el mismo que podremos observar las fases de negociación del protocolo de seguridad SSL y de acuerdo a los requerimientos de la práctica se procede a ir cumpliendo cada uno de los pasos planteados.

1. El cliente le envía al server el número de versión de TLS (o bien de SSL), los cipher que quiere usar, datos generados aleatoriamente, y otros tipos de información 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 conexión envía un mensaje al servidor el cual es “Cliente Hello”, que tiene diferentes características como:

Versión del ProtocoloNúmero aleatorioIdentificador de sesiónAlgoritmo de compresión

Page 3: Ssl Practica

Figura 3. Características de Cliente Hello

Analizando la gráfica obtenida con wireshark se puede visualizar la versión del protocolo siendo este el utilizado por el cliente para la conexión en nuestro caso es el TLS 1.0 (0x0301), así mismo podemos apreciar una cadena de 32 bytes aleatorios que se envían en los mensajes de saludo, los 4 primeros deben ser una marca de tiempo, con precisión de segundos. También se considera el identificador se sesión que es generado aleatoriamente en el servidor, y que permite la reutilización de la sesión en caso de que el cliente lo especifique que en esta sesión es nula ya que no se ha utilizado antes esta página y otro punto que se conoce es el algoritmo de compresión que indica el método empleado para comprimir los mensajes, el único algoritmo de compresión previsto en SSL/TLS es el algoritmo nulo, es decir, sin compresión.

2. El server le envía al cliente el número de versión del TLS (o SSL) del server, los cipher que quiere usar, datos generados aleatoriamente, y otros tipos de información que el cliente necesita para comunicarse con el server vía TLS. El server también manda su propio certificado y, si el server está prestando un servicio que requiera autenticación del cliente, le pide (al cliente) su certificado.

Versión del Protocolo

Número AleatorioIdentificador de sesión

Algoritmo de Compresión

Page 4: Ssl Practica

Figura 4. Server Hello

Como respuesta, el servidor envía un mensaje Server Hello, que contiene esta información:

Versión del ProtocoloNúmero aleatorioIdentificador de sesiónConjunto de algoritmos de cifradoAlgoritmos de Compresión

Figura 5. Características del Server Hello

Versión del Protocolo

Número AleatorioIdentificador de sesión

Algoritmo de CompresiónConjunto de algoritmos de cifrado

Page 5: Ssl Practica

El mensaje Server Hello contiene la “versión del protocolo” que se usará en la conexión, la versión es igual a la que envió el cliente TLS 1.0 (0x0301), en el “identificador de sesión” si el cliente envió uno y el servidor quiere reprender la sesión correspondiente, debe responder con el mismo identificador, si el servidor no quiere reprender la sesión el identificador enviado será diferente. Opcionalmente, el servidor puede no enviar ningún identificador para indicar que la sesión actual nunca no podrá ser respondida, así mismo el “conjunto de algoritmo de cifrado” si se reemplaza una sesión anterior este conjunto debe ser el mismo que se utilizó, finalmente el “algoritmo de compresión” escogido por el servidor o el que se escogió en la sesión que se reprende en el caso de la presente práctica es el mismo algoritmo de cliente es decir nulo.

3. El servidor debe enviar un certificado siempre que esté de acuerdo en que el método de intercambio de clave no es uno anónimo. 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 método 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 pública puede ser de cualquier longitud.

Figura 6. Certificado del Server Hello

Si el servidor puede autenticarse frente al cliente, que es el caso más habitual, envía el mensaje Certificate. Este mensaje normalmente contendrá el certificado del servidor, o una cadena de certificados.

Page 6: Ssl Practica

Si el servidor no tiene certificado, o se ha acordado un método de intercambio de claves que no precisa de él, debe mandar un mensaje Server Key Exchange, que contiene los parámetros necesarios para el método a seguir.

Figura 7. Características del certificado del Server Hello

La versión 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), además también contiene en este certificado el nombre de la entidad a la cual estamos capturando el tráfico, en nuestro caso el Banco Pichicha que utiliza diferentes términos de uso y utilizando la clave pública para este caso hace uso del algoritmo de clave RSA, así el certificado debe autorizar la clave que se usará para la encriptación.

Versión del Protocolo

Nombre de la entidad a la que se emitió el certificado

Clave pública del certificado

Page 7: Ssl Practica

Figura 8. Características de finalización del certificado del Server Hello

Este mensaje es enviado por el server para indicar la finalización de los mensajes ServerHello y sus asociados. Despúes de enviarlo el server esperará una respuesta del cliente. No es un mensaje opcional. Se envía 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 debería verificar la condición de que el server requiera un certificado válido y chequear que los parámetros del mensaje sean aceptables.

4. Usando todos los datos generados en el handshake hasta ahora, el cliente (con la cooperación del server, y dependiendo del cipher siendo usado) crea el premaster secret para esta sesión, lo encripta con la clave pública del server (la cual se obtuvo del certificado del server que éste mandó en el Paso 2), y envía el premaster secret encriptado hacia el server.

Figura 9. Cliente key Exchange

Page 8: Ssl Practica

Figura 10. Características del Cliente key Exchange

El cliente envía un mensaje “ClientKeyExchange”, el contenido del cual depende de intercambio de claves acordado, en el caso de seguir el método de RSA, en este mensaje hay una cadena de 48bytes que se usará como secreto pre-maestro, cifrado con la clave pública del servidor, entonces el cliente y servidor calculan el secreto maestro, que será otra cadena de 48bytes. Para realizar este cálculo, 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 simétrico de los datos, las dos claves Mac.Este mensaje “ClientKeyExchange”, es enviado por el cliente y contiene el PreMasterSecret encriptado por la clave pública del servidor y que se usará finalmente para la encriptación y cálculo de la Mac.

5. Ambas partes (cliente y server) usan el master secret para generar session keys (las claves de la sesión), las cuales son claves simétricas usadas para encriptar y desencriptar la información intercambiada durante la sesión 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 conexión TLS).

Versión del Procotolo

Cipher del Client Key

Fin de mensaje Client Key

Page 9: Ssl Practica

Figura 11. Características de Change Cipher Spec

Este protocolo consiste en un simple mensaje, que es encriptado y comprimido bajo el estado de conexión 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 política (party) de recepción de los subsiguientes registros los cuales estarán protegidos bajo la nueva negociación del ChiperSpec y las claves.

El mensaje Change Cipher Spec es enviado durante el Handshake después que los parámetros de seguridad hayan sido agregados, pero antes el mensaje finished verificador es enviado.

El mensaje Finished sigue inmediatamente la notificación de cambio de cifrado. Su contenido se obtiene aplicando funciones hash al secreto maestro y a la concatenación de todos los mensajes de negociación 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 sesión anterior, será el servidor quien lo enviará primero, justo después del Server Hello.

El contenido del mensajeFinished sirve para verificar que la negociación se ha llevado a cabo correctamente. Este mensaje también 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 usarán en la comunicación.

Versión del Procotolo

Mensaje encriptado de finalización

Page 10: Ssl Practica

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

Conclusiones

La encriptación nos permite convertir un texto normal codificado de forma que las personas que conozcan el código sean incapaces de leerlo, esto permite una mayor seguridad para enviar datos de forma confidencial a través del internet.

La herramienta wireshark nos permite conocer el tráfico que está cursando a través de la red siendo un analizador de protocolos utilizado para realizar análisis 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 envía desde el servidor hacia el cliente para verificar la conexión en nuestro caso lo hace a través del algoritmo de encriptación RSA, en el cuál se enviará la clave pública que se verificará en el cliente con el PreMasterSecret, para completar la conexión.

Las versiones de los diferentes protocolos es la misma, para que se puedan comunicar las diferentes partes del protocolo SSL y no exista una pérdida de datos o se pierda la conexión ya que esta es una transmisión segura.