implementación del protocolo de seguridad tsl

CENTRO DE INVESTIGACIÓN Y ESTUDIOS

AVANZADOS DEL IPN

Proyecto:

Implementación del protocolo de Seguridad TSL

Materia:

Seguridad y Sistemas de Información

Nombres: Efrén Clemente Cuervo Roberto M. Linares Zamora Juan Pablo Flores Ortega

TABLA DE CONTENIDO

I. OBJETIVO DEL PROYECTO 1

II. INTRODUCCIÓN 2

II.1 Antecedentes 2

II.2 Aplicaciones e implementaciones 2

II.3 La competencia de SSL/TLS 2

III. DESCRIPCIÓN DEL PROTOCOLO SSL/TLS 4

IV. ANÁLISIS DEL PROTOCOLOS SSL/TLS 8

IV.1 Vista preliminar. 8

IV.2 El Protocolo TLS 9 El protocolo de registro TLS 10 El protocolo de mutuo acuerdo TLS 10 El Protocolo de cambio de especificaciones criptográficas 11 El Protocolo de alerta 11 El Protocolo de mutuo acuerdo 11 Protocolo de datos de aplicación 12

V. IMPLEMENTACIÓN 13

V.1 Consideraciones de Implementación 13

V.2 Herramientas de implementación 14

V.3 Manejo de Sesiónes SSL conJSSE. 16

V.3 Implementación Real. 16

VI. CONCLUSIONES. 25

VII. BIBLIOGRAFÍA 26

Seguridad en Sistema de Información.

1

II.. OOBBJJEETTIIVVOO DDEELL PPRROOYYEECCTTOO Autenticación de entidades cliente-servidor usando el protocolo de negociación de

TLS: El Protocolo de Negociación (PN) de TLS permite que dos entidades se comuniquen de manera segura utilizando un modelo cliente-servidor. Los tres principales objetivos del PN de TLS son: a) que las entidades acuerden el tipo de criptografía a ser utilizado; b) que ambas entidades se autentiquen a sí mismas a través del uso de certificados digitales c) que las dos entidades creen un secreto compartido o llave de sesión que será utilizado para lograr confidencialidad e integridad en la comunicación de los nodos mientras dure la sesión. El objetivo principal es implementar el protocolo de negociación de TLS utilizando el servidor Apache.


2

IIII.. IINNTTRROODDUUCCCCIIÓÓNN II.1 Antecedentes En 994 Netscape desarrolló la primera versión de SSL en está primera versión jamás

fue implementada de forma pública. Tan sólo unos pocos meses después liberó una importante actualización que vino a llamarse SSL 2.0 y que si tuvo una implementación real a pesar de ir aquejada de importantes errores de diseño. En noviembre de 1995 Netscape publica la especificación para SSL 3.0 la cual, desde entonces, se ha convertido en el estándar ‘de hecho’ para comunicaciones seguras entre clientes y servidores en Internet.

El objetivo de Netscape era crear un canal de comunicaciones seguro entre un

cliente y un servidor que fuese independiente del sistema operativo usado por ambos y que se beneficiara de forma dinámica y flexible de los nuevos adelantos en materia de cifrado a medida de que estos estuvieran disponibles. SSL fue diseñado como un protocolo seguro de propósito general y no teniendo en mente las necesidades específicas del comercio electrónico. SSL trabaja sobre el protocolo TCP y por debajo de protocolos como HTTP, IMAP, LDAP, etc., y puede ser usado por todos ellos de forma transparente para el usuario.

Actualmente existen tres versiones del protocolo, la cuarta es una mejora del SSL v3 y se conoce con el nombre de TLS 1.0, que es la especificación que se va a utilizar en el desarrollo del proyecto.

II.2 Aplicaciones e implementaciones 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.

Existen multitud de implementaciones del protocolo, tanto comerciales como de libre

distribución. Una de las más populares es la biblioteca openssl, escrita en C y disponible bajo licencia GNU. Incluye todas las versiones del SSL y el TLS y un gran número de algoritmos criptográficos, algunos de los cuales ni tan sólo son empleados en el estándar TLS. La biblioteca está disponible en el URL http://www.openssl.org. En esa misma dirección se puede encontrar una lista de referencias a otras implementaciones gratuitas y comerciales de los protocolos SSL y TLS y aplicaciones que los emplean.

II.3 La competencia de SSL/TLS La competencia de SSL recae básicamente en dos tipos de protocolos: los que

conceptualmente se concibieron, al igual que SSL, como protocolos de carácter general para asegurar la información transmitida a través de un canal de comunicaciones y aquellos que se concibieron teniendo en mente el comercio electrónico como propósito específico.


3

En el primer grupo contiene tres protocolos: S-HTTP, PCT, TLS e IPSec. Todos siguen el mismo esquema: en primer lugar se invoca un mecanismo para, mediante criptografía asimétrica, intercambiar una clave secreta de longitud suficiente y, en segundo lugar, se utiliza esta clave para cifrar la información transmitida mediante un algoritmo simétrico mucho más eficiente.

En el segundo grupo se tiene CyberCash y SET. Ambos implementan una

arquitectura mucho más adecuada y orientada para el comercio electrónico en base a una tercera parte de confianza que actúa como intermediaria entre comprador, vendedor y los bancos de ambos.


4

IIIIII.. DDEESSCCRRIIPPCCIIÓÓNN DDEELL PPRROOTTOOCCOOLLOO SSSSLL//TTLLSS SSL trabaja sobre el protocolo TCP y por debajo de protocolos como HTTP, IMAP,

LDAP, etc., y puede ser usado por todos ellos de forma transparente para el usuario. Opera entre la capa de transporte y la de sesión del modelo OSI (o entre la capa de transporte y la de aplicación del modelo TCP) y está formado, a su vez, por dos capas y cuatro componentes bien diferenciados.

El protocolo de registro (Record Protocol) se encarga de encapsular el trabajo de los

elementos de la capa superior, construyendo un canal de comunicaciones entre los dos extremos objeto de la comunicación. El verdadero corazón de SSL está en el protocolo de Handshake que es el encargado de intercambiar la clave que se utilizará para crear un canal seguro mediante un algoritmo eficiente de cifrado simétrico. También es responsabilidad de este protocolo coordinar los estados de ambos extremos de la transmisión.

El protocolo de Alerta es el encargado de señalizar problemas y errores

concernientes a la sesión SSL establecida. Por último, el Change Cipher Spec Protocol está formado por un único mensaje consistente en un único byte de valor 1 y se utiliza para notificar un cambio en la estrategia de cifrado.

A grandes rasgos, se podría decir que SSL trabaja de la siguiente forma: en primer

lugar intercambiamos una clave de longitud suficiente mediante un algoritmo de cifrado asimétrico. Mediante esa clave establecemos un canal seguro utilizando para ello un algoritmo simétrico previamente negociado. A continuación, toma los mensajes a ser transmitidos, los fragmenta en bloques, los comprime, aplica un algoritmo hash para obtener un resumen (MAC) que es concatenado a cada uno de los bloques comprimidos para asegurar la integridad de los mismos, realiza el cifrado y envía los resultados. El estado de todas estas operaciones son controladas mediante una máquina de control de estados. Una sesión SSL puede comprender múltiples conexiones. Adicionalmente, se pueden establecer múltiples sesiones SSL simultaneas.

El protocolo de Handshake es el encargado de negociar los atributos de la sesión

SSL que permitirán construir un canal seguro de comunicaciones. En primer lugar el cliente envía un mensaje Client Hello al servidor el cual debe de responder con un mensaje similar de Server Hello. Estos mensajes son utilizados para dar a conocer ciertas características de ambos: versión del protocolo usada, algoritmos de cifrado conocidos y preferidos, longitudes máximas de clave que admite para cada uno de ellos, funciones hash y métodos de compresión a utilizar.

Adicionalmente cliente y servidor pueden intercambiar dos números generados

aleatoriamente para ser usados como sal. En este momento, además, el servidor asigna un identificador a la sesión y se hace constar la fecha y hora de la misma. El identificador de sesión es enviado al cliente en el mensaje de Server Hello. Si el servidor no respondiera con un mensaje de Server Hello o este no fuese valido o reconocible la sesión abortaría inmediatamente. Generalmente el servidor, el segundo en contestar, elige los algoritmos más fuertes de entre los soportados por el cliente. Si no hay acuerdo en este punto se envía un mensaje de error y se aborta la sesión. A continuación del mensaje de Server Hello, el servidor puede envíar su Certificado (típicamente un X.509) de forma que sea autenticado por el cliente y que, además,


5

este reciba su clave pública. Si no es así, le envía al cliente su clave pública mediante un mensaje de Server Key Exchange (o también si ha enviado su Certificado y este es únicamente para firma y autenticación). Está claro es que al menos uno de estos dos mensajes es necesario para establecer el canal seguro. Un último mensaje que puede enviar el servidor en esta fase de negociación es una solicitud de certificado al cliente. Por último, la fase concluye con el envío, por parte del servidor, de un mensaje de Server Hello Done. Si el Servidor ha solicitado su certificado al cliente, este debe de responder con el o con un mensaje de alerta indicando que no lo posee. A continuación se envía un mensaje de Client Key Exchange donde el cliente envía al servidor, cifrada mediante la clave pública de este, la clave maestra, un número aleatorio generado por el y que actuará como clave del algoritmo simétrico acordado para el intercambio de datos.

Por último, si el cliente ha enviado un certificado y este tiene capacidades de firma,

enviará adicionalmente un mensaje de Certificate Verify firmado digitalmente con objeto de que el servidor pueda verificar que la firma es válida. En este punto el cliente da por concluida la fase mediante un mensaje de Change Cipher Spec seguido, inmediatamente, de un mensaje de Finished que ya va cifrado mediante los algoritmos y claves recién negociados. En respuesta, el servidor envía su propio mensaje de Change Cipher Spec y, a continuación, su mensaje de Finished cifrado con los parámetros negociados. En este momento finaliza la fase de Handshake y cliente y servidor pueden intercambiar datos libremente. Se puede ver un esquema de este intercambio de mensajes en la siguiente figura.

Figura 1. Aplicación SSL


6

Durante la transmisión de datos los mensajes son fragmentados y comprimidos por el protocolo de registro antes de su envío y descomprimidos y reconstruidos por el mismo protocolo al otro extremo de la comunicación. El algoritmo de compresión utilizado es característico de la sesión y se negocia, como se ha visto, en la fase de Handshake.

SSL puede establecer múltiples conexiones dentro de una misma sesión o reanudar

una sesión previamente interrumpida. En ambos casos el intercambio de mensajes de la fase Handshake es mucho más reducido como se describira a continuación.

El cliente envía un mensaje de Client Hello usando el identificador de la sesión

previamente negociada. El servidor verifica si ese identificador es válido y en caso afirmativo devuelve un mensaje de Server Hello usando el mismo identificador de sesión. Acto seguido, envía al cliente un mensaje de Change Cipher Spec y a continuación un mensaje de Finished cifrado ya con los parámetros de la sesión reanudada. El cliente responde con sus propios mensajes de Change Cipher Spec y Finished y seguidamente comienzan a intercambiar datos. Se puede ver este proceso en la siguiente imagen:

Figura 2. Cliente y Servidor SSL


7

Como hemos dicho anteriormente, SSL es capaz de trabajar de forma transparente con todos los protocolos que trabajan sobre TCP. La IANA tiene asignado un número de puerto por defecto a cada uno de ellos que podemos ver en la tabla siguiente:

Identificador Puerto TCP Descripción

https 443 http sobre SSL smtps 465 SMTP sobre SSL nttps 563 NTTP sobre SSL


8

IIVV.. AANNÁÁLLIISSIISS DDEELL PPRROOTTOOCCOOLLOOSS SSSSLL//TTLLSS

IV.1 Vista preliminar. El socket de capa segura fue diseñado para implementar comunicaciones seguras.

Las comunicaciones seguras tienen tres propiedades: confidencialidad, integridad del mensaje y autentificación. La confidencialidad significa que el mensaje mantiene el secreto de posibles espías. La integridad del mensaje significa que el mensaje se puede identificar en tanto que el mensaje sea manipulado (El que envía tiene que estar seguro que se recibió el mensaje que envió). La autentificación significa que se puede ser confidente del destinatario que envía el mensaje.

Dos importantes objetivos del SSL es proporcionar confidencialidad entre el cliente y

el servidor y asegurarse que solo el punto final correcto pueda transferir datos. Los objetivos del API de SSL son emular el socket del API tan cerradamente como sea posible para proporcionar una manera fácil de mover código de los sockets a SSL.

SSL es un protocolo empotrado que se sitúa en la parte más alta de TCP, como se

muestra en la figura 3.

Figura 3. Capa SSL Algunas definiciones necesarias para la comprensión de los siguientes apartados

son: o Firmas Digitales.

La firma digital esta basada bajo el mismo concepto como una persona firma un documento legal. Por ejemplo, un banco envía un documento a un cliente y este necesitar ser firmado y regresado; y el banco tiene que verificar que esa persona firmo el documento en cuestión, por medio de la comparación de una firma previa.

o Firmas Digitales Directas.

Hay dos tipos de firmas digitales: firma digital directa y firma digital arbitraria. La firma digital directa esta justo entre el que envía y el que recibe y usa una llave para descifrar el mensaje. Si hay dos personas en el grupo la llave es compartida.

o Firmas Digitales Arbitrarias.

Una firma arbitraria digital envuelve al que envía el mensaje, una tercera parte confiable y el destinatario. La tercera parte confiable, puede ser como una autoridad certificadora (CA) en el principio de autenticación, el cual asegura la autenticidad y actúa como un árbitro.

SSL/TSLCapa del Socket (BSD Sockets o WinSockets)

TCP UDP

IP

Algoritmo

de Encriptación

y Llaves


9

o Digesto del Mensaje Un digesto del mensaje es una función que toma como entrada un tamaño arbitrario

del mensaje y como salida una cadena arreglada. Dos propiedades importantes del digesto del mensaje son irreversibilidad y resistencia a la colisión. La irreversibilidad significa que es extremadamente difícil computar un mensaje dado su digesto. La resistencia a la colisión significa que es difícil que el mismo digesto halla sido producido del dos mensajes distintos.

IV.2 El Protocolo TLS

El protocolo TLS (Transport Layer Security), como ya se mencionó, es una evolución del protocolo SSL (Secure Sockets Layer). La última propuesta de estándar está documentada en la referencia [RFC_2246].

Los objetivos del protocolo son varios:

1. Seguridad criptográfica. El protocolo se debe emplear para establecer una conexión segura entre dos partes.

2. 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.

3. Extensibilidad. El protocolo permite la incorporación de nuevos algoritmos criptográficos.

4. 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).

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:

1. 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.

2. La conexión es fiable. El transporte de mensajes incluye una verificación de integridad.

El protocolo de registro se emplea para encapsular varios protocolos de más alto nivel, uno de ellos, el protocolo de mutuo acuerdo, permite al servidor y al cliente autentificarse mutuamente y negociar un algoritmo de encriptación y sus claves antes de que el protocolo de aplicación transmita o reciba datos.

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


10

1. 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.

2. La negociación de un secreto compartido es segura. 3. La negociación es fiable, nadie puede modificar la negociación sin ser

detectado por los interlocutores.

El protocolo de registro TLS

El protocolo de registro TLS es un protocolo por capas. En cada nivel los mensajes incluyen campos para el tamaño, descripción y contenido. El protocolo toma un mensaje para ser transmitido, lo divide en bloques, comprime los datos (opcionalmente), los encripta, genera un MAC y transmite el resultado.

En el lado del receptor se sigue un proceso inverso: descifrado, verificación, descompresión y reensamblaje.

El estándar describe cuatro clientes del protocolo:

1. El protocolo de mutuo acuerdo 2. El protocolo de alerta 3. El protocolo de cambio de especificaciones criptográficas 4. El protocolo de datos de aplicación

El protocolo de mutuo acuerdo TLS

El protocolo consta de tres subprotocolos que se emplean para permitir que los interlocutores lleguen a un acuerdo respecto a los parámetros de seguridad para el nivel de registro, se autentifiquen, instancien parámetros de seguridad negociados y se comuniquen condiciones de error.

El protocolo es responsable de negociar una sesión que consta de los siguientes items:

1. Identificador de sesión. Secuencia de bytes aleatoria elegida por el servidor para identificar el estado de una sesión activa o reanudable.

2. Certificado del interlocutor. Certificado X.509 v3 del interlocutor. Este elemento puede ser nulo.

3. Método de compresión. Algoritmo empleado para comprimir los datos antes de encriptarlos.

4. Especificaciones del algoritmo de encriptación. Especifica el algoritmo de encriptación (nulo, DES, etc.) y el algoritmo de firmado (MD5 o SHA). También define atributos criptográficos como el tamaño de la clave de la función de dispersión.

5. Secreto principal. Clave secreta de 48 bytes compartida entre el cliente y el servidor.

6. Reutilizable. Valor que indica si la sesión puede ser empleada para iniciar nuevas conexiones.


11

El Protocolo de cambio de especificaciones criptográficas Este protocolo marca las transiciones entre distintas estrategias de cifrado. Consta

de un mensaje que se encripta y comprime con las especificaciones actuales de la conexión (no las pendientes).

Cuando el destinatario recibe este mensaje la capa de registro copia el estado de lectura pendiente al estado de lectura actual. De forma similar, el emisor cambia su estado de escritura al enviar este mensaje.

Este mensaje se envía durante el acuerdo, después de haber acordado los parámetros de seguridad pero antes de que se envíe el mensaje de verificación finalizada.

El Protocolo de alerta Uno de los tipos de mensaje que soporta la capa de registro es el de alerta. Estos

mensajes incluyen la severidad de la alerta y una descripción de la misma. Los mensajes de alerta con nivel de fatal provocan la inmediata terminación de la comunicación.

Existen distintos tipos de alertas:

• Alerta de cierre. El cliente y el servidor deben saber que la conexión se está cerrando para evitar un ataque de truncado. Cualquiera de los dos puede iniciar el intercambio de mensajes de cierre. Cualquier información recibida después de la alerta de cierre es ignorada.

• Alerta de error. La gestión de errores el protocolo de mutuo acuerdo es muy simple, cuando uno de los interlocutores detecta un error lo envía al otro y, si se trata de un error fatal, cierran la conexión.

El Protocolo de mutuo acuerdo Los parámetros del estado de la sesión son producidos por este protocolo, que opera

sobre el protocolo de registro TLS. Cuando un cliente y un servidor empiezan a comunicarse, acuerdan la versión del protocolo, selección de algoritmos criptográficos, opcionalmente se autentifican mutuamente y emplean algoritmos de clave pública para generar secretos compartidos.

El protocolo de mutuo acuerdo consta de los siguientes pasos:

1. Intercambio de mensajes de saludo (hello messages) para acordar los algoritmos a emplear, intercambiar valores aleatorios y verificar si es una sesión reanudada.

2. Intercambiar los parámetros criptográficos necesarios para permitir que el cliente y el servidor acuerden un pre-secreto.

3. Intercambio de certificados e información criptográfica para permitir que cliente y servidor se autentifiquen.

4. Generar un secreto principal a partir del pre-secreto e intercambiar valores aleatorios.

5. Proporcionar los parámetros de seguridad a la capa de registro. 6. Permitir al cliente y al servidor verificar que su interlocutor a calculado los

mismos parámetros de seguridad y que el acuerdo se produjo sin alteraciones por parte de un tercero.


12

Protocolo de datos de aplicación Los mensajes de datos de la aplicación son transportados por la capa de registro y

son fragmentados, comprimidos y encriptados basándose en el estado actual de la conexión. Los mensajes se tratan como datos transparentes para la capa de registro.


13

VV.. IIMMPPLLEEMMEENNTTAACCIIÓÓNN

V.1 Consideraciones de Implementación SSL/TSL hace una distinción entre una conexión y una sesión. Una sesión

representa el algoritmo negociado y el master_secret, es decir cada vez que una sesión es establecida la master_secret es negociada. Una conexión es un canal de comunicación específica alo largo de las llaves asociadas, cifras, etc.

SSL permite una manera de burlar el hadshake, dado que es caro (en el tiempo de

CPU y de las rondas), si el cliente y el servidor ya se han comunicado una vez. A el cliente y el servidor se les permite establecer una nueva conexión usando un master_secret del anterior hadshake y cada conexión tiene un diferente conjunto de llaves porque es almacenado por la combinación del anterior secreto maestro con un número aleatorio.

La primera vez que el cliente interactúa con el servidor, ambos el cliente y el servidor

crean una sesión y una conexión. El servidor manda un session_id en el mensaje ServerHello y captura master_secret. Cuando el cliente inicia una nueva conexión con el mismo servidor, esta usa un session_id en el mensaje de ClientHello y el servidor resume la sesión usando session_id la de el serverHello (figura 5) El resto de handshake es saltado; esto es más rápido dado que se rehúsa el material de las llaves procesado anteriormente.

En la figura x4 el servidor inicializa la autentificación por medio de la petición de un

certificado (via el mensaje CertificateRequest). El cliente manda un mensaje Certificate y un mensaje de CertificateVerify (con la llave privada asociada con el certificado) para identificarse el mismo. Si el cliente no tiene certificado, un mensaje de Certificate sin certificados podria ser mandado y el servidor decidiría si continua o no sin autenticación o con otros significados de autenticación; de otra forma el servido envía un fatal handshake_failure.


14

Figura 4. SSL Handshake con autenticación de clientes.

V.2 Herramientas de implementación SSL es una herramienta popular para el encriptado de tráfico entre en cliente y el

servidor, por lo que las sesiones son encriptadas usando información certificada del lado del servidor y puede también requerir que el cliente se autentifique el mismo. Una de las herramientas que se utiliza para la implementación de este proyecto es la utilización de extensiones de sockets seguros de java (JSSE), la cual proporciona una API estándar para encapsular el protocolo SSL para el uso de clientes y servidores de SSL.

JSSE es una extensión de java sockets para proporcionar funcionalidad extendida

para SSL y TLS. Los sockets manejan su nombre desde muros de sockets, donde la electricidad es proporcionada a través de una conexión del muro hasta un dispositivo eléctrico. Como una conexión de electricidad un socket proporciona una conexión de datos.

Los protocolos TLS y SSL proporcionan funcionalidad para encriptación de datos,

autentificación de servidores, integridad de mensajes y autenticación de clientes. La interfase JSSE, al igual un soket de interfase, trabaja sobre una capa de sesión.

Las aplicaciones padres que operan a nivel de aplicación, como HTTPS, FTP y Telnet, son medios para usar sockets para manejar las comunicaciones TCP (UDP) y el handshake.

Cliente Cliente

ClientHello

ServerHello

Certificate

CertificateRequest

ServerHelloDone

Certificate

ClientKeyExchange

CertificateVerify

Finished

Finished


15

Estas aplicaciones tratan con el soporte de protocolos de aplicaciones que requieren

múltiples conexiones y sesiones. Algunas de las aplicaciones que usan HTTPS requieren JSSE para algunas conexiones y java Sockets para otras, dependiendo de que aplicaciones requerirán un conexión segura y cuales no requerirán conexión de seguridad, durante la implementación de un proceso concurrente. Justo como los sockets de java ocultan las implementaciones de ethernet de una sesión y una conexión, el protocolo JSSE oculta estas capas conocidas como llaves de handshaking e implementaciones de cifras. La conexión es el mecanismo general de transporte y una sesión es el estado específico de información compartido entre los pares.

La conexión del socket proporciona un transporte entre dos pares, el cliente y el

servidor, justo como un cable de poder proporciona energía a una conexión entre un dispositivo y la fuente de voltaje. Las capas del modelo OSI proporciona las definiciones de los paquetes.

La sesión del socket es la instancia y el estado entre un cliente específico y un

servidor. Esto incluye el protocolo handshake, llaves, parámetros de seguridad y cualquier tipo de información especifica sobre el cliente y el servidor. La herramienta JSSE, encapsula implementación sockets, encriptación y la pila de TCP/IP, como se muestra en la figura 6

Figuran 5. JSSE encapsula sockets y capas TCP/IP

Los siguientes paquetes comprenden la arquitectura de JSSE: Java.net.ssl: Este paquete contiene todo el núcleo de clases y las interfases

para la API JSSE. Java.net: Este paquete contiene la funcionalidad de los sockets para el cliente y

el servidor Java.security.cert: Este paquete es necesario para soportar la funcionalidad

de la administración de certificados básicos.


16

La arquitectura JSSE es primordialmente útil para encapsulación de los sockets de SSL, el socket de objetos del servidor SSL y factores.

Rol de clases API o interfase de la arquitectura JSSE. SSLSocket: Socket que soporta los protocolos de seguridad SSL, TLS y WTLS. SocketFacotry: Fabrica para sockets de objetos. La fabrica crea los soportes de

las clases para los sockets. SSLSocketFactory: Fabrica de objetos SSLSocket. SSLServerSocket, ServerSocketFactory, SSLServerSocket

SSLsessión y SSLsession, etc.

V.3 Manejo de Sesiónes SSL conJSSE.

Una javax.net.ssl.SSLSession representa un contexto seguro de negociación entre el cliente y el servidor. Una vez que una sesión es creada, esta es usada entre las mismas conexiones del cliente y el servidor. La sesión contiene la cifra adecuada, la información de conexión y la administración de información que será usada bajo el socket seguro de conexión. La sesión puede ser vista como medio para salvar la llave de información del socket de conexión. Uno de los accesorios que puede ser salvado es el ID de sesión que identifica una sesión particular. Otros accesos incluyen la creación de tiempo de sesión, los certificados, la cifra del nombre y la SSLSessionContext. Tal y como se muestra en la implementación del proyecto.

Una SSLSession es asociada con la obtención de información de una conexión

dada. Sin embargo, un cliente y un servidor pueden contener las conexiones y las parejas de esas conexiones. Para encapsular un conjunto de SSLSessions, un SSLSessionContext es usado para contener los conjuntos de SSLSession del cliente y servidor que son asociados con la conexión. Una SSLSession individual puede ser salvada por el método getSession() sobre un socket particular del cliente. También, el SSLSessionContext que s salvado de el SSLSession contiene un conjunto de más SSLSession que pueden ser parte de los sockets de entidad.

V.3 Implementación Real. A continuación se describe la implementación del proyecto. La implementación del proyecto se realizo en dos fases: una implementación a nivel

de sockest y una aplicación que permite conexiones TSL en un servidor Apache., utilizando para su desarrollo la plataforma java JSSE 1.4, descrita anteriormente. JSSE es una extensión de java sockets para proporcionar funcionalidad extendida para SSL y TLS.

El desarrollo se llevo acabo en un equipo Pentium 4 a 1.7 MHz con 128 M de memoria

RAM.


17

• 1ª Fase: Implementación de los Sockest. La implementación de los sockest se describe en el siguiente figura 7. Esta muestra

la arquitectura que se implemento entre el cliente y el servidor, utilizando sockets seguros.

Figura 6. Arquitectura del sistema. De acuerdo a esta arquitectura se crearon dos módulos, un para el cliente y otro

para el servidor. El cliente funciona de la siguiente manera: Se ejecuta desde la línea de comandos:

java GUIClient Entonces a parecerá la siguiente interfaz grafica de usurario (figura 8)

Figura 7. Interfaz grafica de usuario. Una vez que se inicia la aplicación y es presionado el botón de “conectar”, la

aplicación intenta conectarse a la dirección y al puerto previamente establecido, utilizando el repositorio de certificados seleccionado.

Entonces si la conexión tiene éxito, en el cuadro de texto del proceso se vera lo

siguiente (figura 9):

Cliente Servido

Puerto P

Puerto P


18

Figura 8. Conexión al servidor. Cuando se comienza la aplicación del servidor, se puede observar como va

inicializando la conexión del socket, el intercambio TLS, la inicialización del almacén de certificados (StoreKey) y el gestor de sockets seguros a partir del almacén de certificados.

En la figura 10, se aprecia el proceso que se esta llevando a cabo durante la

evolución de la conexión. Así, si la conexión tiene éxito entonces vermos:

Figura 9. Evolución de la conexión. Una vez terminado el proceso, se puede apreciar la conexión realizada, la cual nos

brinda mas información de lo realizado por parte del cliente (figura 11). Sin embargo


19

también se puede observar de manera mas clara lo realizado entre los sockets, si se tiene activado el volcado de flujo entre sockets.

En la pestaña de debug se observa claramente los bytes que son intercambiados

entre los sockets, de esta forma se puede analizar: el certificado recibido por el servidor, el cifrador que se usara entre los sockets y los bytes decodificados que llegan provenientes del servidor, los mensajes de alerta, etc.:

Figura 10. Conexión realizada. Ahora, del lado del servidor se tiene algo similar al caso anterior; para cargarlo se

debe teclear desde la línea de comandos: java GUIClient

Entonces a parecerá la siguiente interfaz grafica de usurario (figura 12)

Figura 11. Interfaz del servido.


20

Así, para iniciar al Servidor que atenderá las conexiones seguras por el puerto especificado utilizando el repositorio de certificados elegido por el usuario simplemente presionamos el botón de “conectar”.

De esta forma el servidor se pondrá en espera de conexiones y cuando un cliente

intente conectarse entonces el cuadro de texto del proceso mostrara el paso en el que se encuentra, esto lo podemos ver en la figura 13:

Figura 12. Conexión al servidor.

Cuando se comienza la aplicación del servidor, se puede observar como va

inicializando la conexión del socket TLS y establece las conexiones y el tipo de autentificación para el cliente, la espera del conexión y de datos seguros a partir del cliente.

De igual forma que en el cliente el servidor tiene la opción de permitir ver el volcado

entre la comunicación realizada, en la pestaña de Debug podríamos observar dicho volcado (figura 14):

Figura 13. Conexión al servidor.


21

• 2ª Fase: Implementación de TSL para un servidor Apache

Con los conocimientos adquiridos de la 1ª implementación se planteo el siguiente

esquema para proveer a un servidor apache de la funcionalidad del protocolo TSL (figura 15):

Figura 14. Arquitectura de la implementación de TSL sobre un servidor Apache.

De acuerdo a esta arquitectura se crea el modulo para el servidor. El servidor

funciona de la siguiente manera: Se ejecuta desde la línea de comandos: java TSLWrapper

Entonces aparecerá la siguiente interfaz grafica de usurario (figura 16)

Figura 15. Interfaz grafica..

Servidor Apache

TLS Proxy

HTTP

Comunicación local mediantesockets normales enel puerto SO.

MANLANWAN

Puerto 443 (HTTPS)

El servidor TLS proveeuna capa extra al servidorApache, utilizando TSL


22

Donde se establecerán los parámetros básicos como: Puerto, Archivo de Almacén

de certificados, etc. Al presionar el botón de “Iniciar Servidor” se activará una conexión local en el puerto 80 con el servidor Apache y se creara un socket seguro de tipo servidor el cual esperará por conexiones de tipo TSL. De la misma forma que en la primera fase se establecieron dos campos de texto uno donde se describe el proceso que se esta llevando a cabo y otro apartado donde se ve el volcado de los datos transmitidos por la conexión segura (figura 17).

Figura 16. Proceso de conexión servidor. De esta forma el servidor se queda esperando por conexiones externas en el puerto

de HTTPS(443). Cuando un cliente se conecta al servidor en el cuadro de texto de Debug se puede apreciar el flujo de datos en la comunicación establecida por los sockets seguros, de acuerdo al protocolo de TSL (figura 18).

Figura 17. Flujo de datos en el Socket.


23

Sí, cuando el cliente (típicamente un navegador WEB) decide conectarse al servidor,

este establece el protocolo de TSL enviándole la petición para que dicho cliente acepte el certificado del servidor con el cual pretende autenticarse.

En la figura 19 se muestra como la petición de conexión de un cliente es contestada

por el servidor enviándole su certificado.

Figura 18. Petición de conexión de un cliente Si se desea se puede observar los datos que contiene el certificado enviado por el

servidor (figura 20), y de esta manera aceptar o no la conexión segura con el servidor:

Figura 19. Datos que contiene el certificado enviado por el servidor


24

Ahora, si el certificado decide ser aceptado por el cliente, entonces se establece una comunicación segura por medio del protocolo de TSL, y de esta forma obtenemos los datos correspondientes a la pagina, solicitada por medio de un canal seguro de comunicación.

Figura 20, Servidor Apache.

En la figura 21, se muestra la comprobación del servicio del servidor de Red Apache.

Esta implementación realizada puede ser utilizada en cualquier servidor WEB lo único que será necesario es que el Servidor de TSL tendría que estar corriendo en todo momento para proporcionara este servicio.


25

VVII.. CCOONNCCLLUUSSIIOONNEESS.. Hay un hecho evidente que en el futuro la necesidad de contar con redes de

comunicaciones seguras se incrementará. Lo que no es tan fácil de prever es por cuanto tiempo mantendrá SSL/TLS su supremacía en estos terrenos. Lo lógico sería pensar que en el terreno de las comunicaciones seguras de propósito general se vea desplazado en algún momento por alguna nueva tecnología en el terreno específico de las aplicaciones de comercio electrónico o por algún otro protocolo diseñado a tal efecto. El momento en el que esto ocurrirá es mucho más difícil de prever.

Por el momento y lo que hemos tratado de reflejar en este proyecto, SSL/TLS se

mantiene como una de las herramientas más importantes y factibles para comunicaciones seguras, porque no existe ninguna otra opción mejor. En el terreno de los protocolos de propósito general hay tres grandes grupos: los que son más restrictivos que SSL en cuanto a posibles aplicaciones (como S-HTTP), los que no aportan nada nuevo a lo que ya hace bien SSL y los que aportando mejores mecanismos y más seguridad se ven desfavorecidos por su mayor costo de implantación y mantenimiento (lo cual es el caso de IPSec).


26

VVIIII.. BBIIBBLLIIOOGGRRAAFFÍÍAA 1. E. Rescorla. SSL and TLS, Designing and Building Secure Systems. Addison- Wesley. 2000. 2. S. Feit. TCP/IP, Arquitectura, protocolos, implementación y seguridad. Osborne MCGraw-Hill. 1997. 3. W.R. Stevens. TCP/IP Illustrated Volume 1: The Protocols. Addison-Wesley. 1994. 4. J.Viega, M.Messier and P.Chandra. Network Security with OpenSSL, Cryptography for Secure Communications. O’Really. 2002.

implementación del protocolo de seguridad tsl

Documents