transport layer security protocol - cybsec.com

ESPE-MGS-VIII SEGURIDAD INFORMATICA Protocolo TLS

1

TTrraannssppoorrtt LLaayyeerr SSeeccuurriittyy PPrroottooccooll

MMAAEESSTTRRIIAA EENN GGEERREENNCCIIAA DDEE SSIISSTTEEMMAASS OOCCTTAAVVAA PPRROOMMOOCCIIOONN

TTRRAABBAAJJOO DDEE SSEEGGUURRIIDDAADD IINNFFOORRMMAATTIICCAA PPRROOFF:: LLIICC.. JJUULLIIOO CCEESSAARR AARRDDIITTAA -- CCYYBBSSEECC SS..AA..

IINNTTEEGGRRAANNTTEESS

HHuuggoo AAllvvaarreezz VV..

SSeegguunnddoo SSaarráánnssiigg AA..

QQuuiittoo--EEccuuaaddoorr,, JJuulliioo--1122--22000077


2

CCOONNTTEENNIIDDOO

CAPITULOS

PAGINA

1. RESUMEN EJECUTIVO 3 2. INTRODUCCION 3 3. COMERCIO ELECTRONICO 4 4. ALGUNOS PROTOCOLOS DE ENCRIPCION 5

4.1. SSH (Secure Shell) 5 4.2. SSL (Secure Socket Layer) 6 4.3. HTTPS 6

5. DESCRIPCION DE TLS Y SU ORIGEN 6 6. OBJETIVOS DE TLS 7 7. ESTRUCTURA DE TLS 7

7.1. El TLS Record Protocol 7 7.1.1. Estados de Conexión 8 7.1.2. El Record Layer 9

7.2. El TLS Handshake Protocol 10 7.2.1. Propiedades de Handshake Protocol 10 7.2.2. Subprotocolos de Handshake Protocol 10 7.2.3. Secuencia de una conexión segura 11

8. LA AUTENTICACION 13 8.1. Tipos de Certificados 14 8.2. Autenticación del Servidor 14 8.3. Autenticación del Cliente 15

9. DIFERENCIAS ENTRE SSL y TLS 16 10. APLICACIONES DE CON TLS 17 11. ESTANDARES RELACIONADOS TLS 18 12. PROTOCOLO WTLS 19 13. CONCLUSIONES 20 14. TERMINOLOGIA 20 15. REFERENCIAS 22


3

1. RESUMEN EJECUTIVO:

La protección de datos es un tema de creciente actualidad que, en el sector de las telecomunicaciones, ha incrementado su interés debido al crecimiento de clientes que utilizan nuevas tecnologías. Un sinónimo de la globalización es justamente la evolución vertiginosa que el comercio electrónico ha tenido lugar. Pues hemos de considerar que esta herramienta económica por ahora se ha vuelto en una ventaja competitiva. Pero surge el dilema de cómo asegurar que los principios fundamentales de seguridad como: confidencialidad, integridad y disponibilidad no sean violentados. Para ello como es de saber, han surgido algunos avances sobre todo con productos que actúan en la capa de transporte. Ejemplos de ellos son los protocolos de seguridad basados en complejos algoritmos de criptografía: SSH, SSL, WTLS, etc. Siendo el protocolo SSL 3.0 la versión más ampliamente difundida en la actualidad también ha sido sujeta de varias mejoras dando lugar al surgimiento por ahora del protocolo TLS 1.1. Como se podrá evidenciar en las siguientes páginas, se hace un estudio detallado del protocolo en cuestión y las diversas aplicaciones que en la actualidad están utilizándolo como protocolo que asegura la entrega/recepción de datos entre la capa de red y aplicación. Varias son las aplicaciones (http, smtp, nntp, etc.) que utilizan éste protocolo, pero sobre todo con mayor presencia en aplicaciones sobre Internet vía HTTPS.

2. INTRODUCCION:

En la actualidad la seguridad de la información es muy importante, en el sitio www.gocsi.com podemos ver que éste viene realizando encuestas de seguridad por muchos años y de donde se concluye que el 78% de accesos a Internet es el punto de más vulnerabilidad, y también vemos que la mayoría de las empresas destinan entre 1% y 2% de su presupuesto a temas de seguridad. Compañías que desean surgir, simplemente han optado por ofrecer sus bienes y servicios sobre Internet apoyándose en herramientas que por ahora con seguridad le garantizan que sus transacciones se las haga de modo seguro. TLS y su antecesor SSL, han ofrecido la seguridad buscada y que se han convertido de echo en los productos preferidos para poner a disposición del mundo sitios de comercio electrónico seguros y avalados más aún por entidades certificadoras como VeriSign por ejemplo. Tenemos hoy en día tiendas comerciales que brindan la posibilidad de realizar compras vía Web a través de pagos vía tarjeta de crédito o aplicaciones de intercambio seguro de correo. Este documento trata justamente los detalles a través de los cuales las transacciones electrónicas son garantizadas. Se lo ha divido en dos partes principales:

a) En la primera parte hacemos una breve sinopsis de lo que es el comercio electrónico y

algunos protocolos de seguridad existentes (numerales 3 y 4) b) En la segunda parte que inicia en el numeral 5, se hace una referencia absoluta del

protocolo TLS 1.1, donde en detalle trataremos temas como: los orígenes de TLS, Objetivos de éste protocolo, Arquitectura de TLS, mecánica de autenticación que el protocolo emplea, algunas diferencias entre TLS y SSL, Aplicaciones que usan TLS, etc. Finalmente el trabajo concluye con una breve referencia de WTLS y conclusiones.


4

3. COMERCIO ELECTRONICO:

El comercio electrónico ha presentado una evolución vertiginosa en los últimos años. Lo que comenzó con transacciones comerciales electrónicas se ha convertido en una herramienta imprescindible tanto a nivel particular como empresarial. Hoy en día, el comercio electrónico es uno de los principales medios para realizar transacciones comerciales y se espera que crezca de forma exponencial. No obstante, el crecimiento acelerado del uso de la Internet sobre todo en América Latina ha sido de los más rápidos en el mundo. Estos acontecimientos indican que mientras el comercio electrónico tiene un enorme potencial para ampliar el comercio y aumentar la competitividad de las diferentes regiones en los mercados internacionales, el reto reside en asegurar que el comercio electrónico contribuya a la integración y al desarrollo de todas las naciones. No obstante, es menester aprovechar las oportunidades y generar un entorno propicio a fin de evitar la profundización de desigualdades en cuanto al acceso y uso de las tecnologías de información, lo cual podría ampliar la brecha social y económica entre los países del mundo. El comercio electrónico puede ayudar a superar las desventajas creadas por las largas distancias y los obstáculos geográficos y posibilitar el acceso a los mercados de cada país a costos sustancialmente menores. Los dividendos podrían ser particularmente altos para las compañías y economías más pequeñas de la región, que tradicionalmente se han visto perjudicadas por la falta de información, los altos costos de acceso a los mercados y la distancia que los separa de éstos. Si bien la mayor parte de las ganancias ocurrirán probablemente en el comercio electrónico inter-empresarial, sobre todo en el sector de los servicios bancarios y financieros, las compras en línea por parte de los consumidores continuarán creciendo, y se prevé que ambos sectores en un mediano plazo se constituyan la fuerza motora de la economía global. Para los gobiernos, las tecnologías de información facilitan los medios para llegar a los ciudadanos y brindar nuevas oportunidades para el intercambio de información y la transparencia, la capacitación, el aprendizaje y el desarrollo. Al mismo tiempo, los gobiernos pueden reducir costos de actividades, sean éstas operativas, de compras o contratación. Las ganancias resultantes en términos de productividad propulsarían las economías de los países, conducirían hacia un mayor nivel de vida de sus ciudadanos y generarán nuevas oportunidades para el bienestar y el desarrollo de las comunidades.

El comercio electrónico puede hacer una importante contribución al futuro crecimiento económico sostenible del mundo, sin embargo, existen varios desafíos que han de ser superados para poder aprovechar a plenitud los potenciales beneficios económicos y sociales que ofrece el comercio electrónico; con respecto a la infraestructura, el crecimiento del comercio electrónico se ha desacelerado por los obstáculos que representan la baja calidad de la infraestructura de telecomunicaciones, la estrechez del ancho de banda y los altos costos de conexión en algunos países. La confiabilidad y los costos asociados a la entrega de bienes constituyen una barrera adicional. El aumento de la participación y la expansión del uso de la Internet en todos los países del mundo dependerán de una mayor conciencia entre las personas y empresas, en especial la pequeña y mediana empresa, así como de la formación de una base de recurso humano capacitado para utilizar y crear mediante el uso de las tecnologías digitales.


5

Los marcos jurídicos, comerciales y financieros fueron creados para las transacciones físicas y podrían resultar insuficientes en la actualidad para garantizar el respeto y cumplimiento de contratos, asegurar la validez de las firmas electrónicas y proteger de forma eficaz los derechos de propiedad intelectual en apoyo al crecimiento de las transacciones electrónicas es un reto. En un principio, el medio electrónico no crea la confianza que caracteriza a las transacciones realizadas personalmente. Actualmente persiste la incertidumbre entre los consumidores, tanto las personas naturales como las empresas, de que quizás no reciban del mundo en línea un nivel de protección similar al que obtienen en el mundo físico en cuanto a la privacidad, seguridad, autenticación y protección al consumidor. El comercio electrónico es inherentemente global y no conoce fronteras. Las políticas y actividades de comercio electrónico (nacionales, regionales, del sector público o privado) alcanzarán su mayor eficacia si son compatibles con un enfoque mundial. Es necesaria la cooperación internacional para evitar que los enfoques nacionales fragmenten los mercados regionales y mundiales y restrinjan el comercio de forma indebida, gobiernos, empresas y consumidores deben trabajar mancomunadamente para crear un entorno en el cual el comercio electrónico pueda crecer para maximizar los beneficios económicos y sociales para todos. Los gobiernos deben tomar medidas para satisfacer el interés público y crear un entorno de normas y políticas para el comercio electrónico que sean flexibles, estimulen la innovación y la competencia y no favorezcan a ninguna tecnología en particular. El sector privado debe desempeñar un papel de liderazgo en la estimulación del crecimiento del comercio electrónico a través de la inversión y la innovación. Pensando en todas las ventajas y beneficios que el concepto como tal trae, la tecnología como tal ha desarrollado y ha puesto a disposición herramientas que justamente apoyen el desarrollo de ésta actividad. Tenemos como ejemplo el desarrollo protocolos de seguridad en transportación de la información que vía algoritmos complejos de criptografía garantizan justamente el entorno comercial electrónico. De todos depende que esto sea utilizado de buena manera evitando de alguna manera cerrar brechas que hasta ahora siguen abiertas y quien no lo haga, simplemente corre el riesgo de quedarse aislado frente a éste dinámico entorno de negocios.

4. ALGUNOS PROTOCOLOS DE ENCRIPCION

Al margen del protocolo TLS, que más adelante detallaremos tenemos de algunos de los más utilizados:

4.1. SSH (Secure Shell):

SSH permite a los usuarios registrarse en sistemas de host remotamente. A diferencia de rlogin o telnet SSH encripta la sesión de registro imposibilitando que alguien pueda obtener una contraseña de texto. SSH está diseñado para reemplazar los métodos comunes para registrarse remotamente en otro sistema a través de la shell de comando. El programa scp reemplaza otros programas diseñados para copiar ficheros entre hosts como por ejemplo FTP o RCP. Ya que estas aplicaciones antiguas no encriptan contraseñas entre el cliente y el servidor, las evita


6

siempre que sea posible. El uso de métodos seguros para registrarse remotamente a otros sistemas hará disminuir los riesgos de seguridad para ambos sistemas y el sistema remoto.

La forma en que se entabla una comunicación es en base la misma para todos los protocolos seguros:

a) El cliente envía una señal al servidor pidiéndole comunicación por el puerto 22. b) El servidor acepta la comunicación en el caso de poder mantenerla bajo encriptación

mediante un algoritmo definido y le envía la llave pública al cliente para que pueda descifrar los mensajes.

c) El cliente recibe la llave teniendo la posibilidad de guardar la llave para futuras comunicaciones o destruirla después de la sesión actual.

Se recomienda que si se esta en un computador propio, la clave sea guardada, en otro caso, destruirla

4.2. SSL (Secure Socket Layer) :

El protocolo SSL fue desarrollado por Netscape para permitir confidencialidad y autenticación en Internet. SSL es una capa por debajo de HTTP y tal como lo indica su nombre esta a nivel de socket por lo que permite ser usado no tan solo para proteger documentos de hipertexto sino también servicios como FTP, SMTP, TELNET entre otros.

La idea que persigue SSL es encriptar la comunicación entre servidor y cliente mediante el uso de llaves y algoritmos de encriptación.

4.3. HTTPS:

El protocolo HTTPS es la versión segura del protocolo HTTP, el sistema HTTPS utiliza un cifrado basado en SSL para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. Cabe mencionar que el uso del protocolo HTTPS no impide que se pueda utilizar HTTP. Es aquí, cuando nuestro navegador nos advertirá sobre la carga de elementos no seguros (HTTP), estando conectados a un entorno seguro (HTTPS). Los protocolos HTTPS son utilizados por navegadores como: Safari (navegador), Internet Explores, Mozilla Firefox, Opera entre otros. Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas. El protocolo HTTPS es una versión segura del protocolo HTTP que implementa un canal de comunicación seguro y basado en SSL/TLS entre el navegador del cliente y el servidor HTTP.

5. DESCRIPCION DE TLS Y SU ORIGEN:

SSL (Secure Sockets Layer) 3.0 desarrollado por Netscape se publicó en 1996, que más tarde serviría de base para desarrollar el protocolo TLS (Transport Layer Security) 1.0. El


7

estándar del protocolo TLS, tiene su origen en el RFC 22461. En la actualidad está en vigencia la versión 1.1 referenciada en el RFC 43462 y en proceso de desarrollo la versión 1.2. TLS es un protocolo para establecer una conexión segura entre un cliente y un servidor, con capacidad de autenticar tanto al cliente como al servidor y crear una conexión cifrada entre los dos. Este protocolo es utilizado de manera masiva para brindar seguridad a nivel de la capa de transporte, garantizando de esta manera autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Visa, MasterCard, American Express y muchas de las principales instituciones financieras han aprobado SSL/TLS para garantizar seguridad en tendencias globales de e-commerce.

6. OBJETIVOS DE TLS:

En orden de prioridad según el RFC 4336, los objetivos de TLS son los siguientes:

a) Seguridad criptográfica: TLS puede ser usado para establecer conexiones seguras entre dos entidades.

b) Interoperabilidad: Los programadores independientes deberían poder desarrollar aplicaciones usando TLS que puedan luego intercambiar parámetros criptográficos exitosamente, aun cuando un programador no conociera el código del otro.

c) Extensibilidad: TLS busca ser extensible de manera que se le puedan añadir nuevos métodos de codificación cuando sea necesario.

d) Eficiencia relativa: como las operaciones criptográficas tienden a ser altamente intensivas en el uso del CPU, TLS trata de reducir el número de conexiones que deben ser establecidas desde cero usando session caching. Además, en su diseño se ha cuidado reducir la actividad de red que su uso genera.

7. ESTRUCTURA DE TLS:

Figura No. 7.1 - Protocolo TLS

Como podemos ver en el gráfico anterior, TLS está en la capa de transporte y básicamente está formado por dos componentes: el TLS Record Protocol y el Handshake Protocol. 7.1. El TLS Record Protocol: Es utilizado para la encapsulación de varios protocolos de nivel superior, uno de ellos es el TLS Handshake Protocol, el cual es utilizado para autenticar tanto a los clientes como a los servidores, y para negociar un algoritmo de cifrado así como las llaves criptográficas,

1 RFC 2246 – Contiene las especificaciones de la versión 1.0 del protocolo TLS. 2 RFC 4336 – Contiene las especificaciones de la versión 1.1 del protocolo TLS.


8

antes de que el protocolo de la aplicación transmita o reciba el primer byte de datos. En definitiva, ofrece seguridad en las conexiones y tiene dos propiedades básicas:

Figura No. 7.2 – Esquema general de TLS Record Protocol

a) La conexión es privada; se utiliza criptografía simétrica para el cifrado de los datos (DES, AES, RC4, etc), las llaves para los algoritmos simétricos son generadas una sola vez para cada sesión, y están basadas en un secreto negociado por otro protocolo (TLS Handshake), el TLS Record Protocol puede ser utilizado sin cifrado también.

b) La conexión es confiable, el transporte de mensajes, incluye una verificación de

integridad de mensajes, utilizando una MAC3 con llave, para esto se utilizan algoritmos de funciones de hash seguros como SHA1, SHA256, MD5.

7.1.1. Estados de Conexión:

Existen dos estados: actuales y pendientes de lectura y escritura cada uno. Los registros sólo se procesan bajo el estado actual. Es posible pasar de un estado pendiente de conexión a un estado actual por medio de Handshake Protocol. Cada estado de una conexión define primeramente los parámetros de seguridad.

Cuadro No. 7.1 – Parámetros de Seguridad de una Conexión

3 En criptografía, Message Authentication Code o MAC (del inglés, código de autenticación de mensajes) es un código que se genera a partir de un mensaje de longitud arbitraria y de una clave secreta compartida entre remitente y destinatario, y que sirve para autenticar el mensaje. También se lo llama cryptographic checksum


9

En segundo lugar el Record Protocol genera estos cuatro elementos: los Cliente y Server write MAC secret y Client y Server write key. Por cada registro procesado se deben actualizar los estados actuales. Cada estado comprende los elementos detallados en el siguiente cuadro:

Cuadro No. 7.2 – Elementos de cada estado actual

7.1.2. El Record Layer: En esta capa se realiza lo siguiente:

a) Fragmentación:

El Record Layer de TLS recibe datos no interpretados de capas superiores en bloques no vacíos de cualquier tamaño, y los fragmenta en bloques de información de hasta 2^14 bytes o menos. Muchos mensajes del cliente del mismo ContentType pueden unirse en un solo TLS PlainText record, o un solo mensaje puede fragmentarse en varios registros. Una vez hecha la fragmentación (si es que es necesaria) se introduce la información en una estructura llamada TLSPlaintext.

Figura No. 7.3 – Estructura de un mensaje

b) Compresión y Descompresión:

Durante la conexión se puede especificar un algoritmo de compresión y descompresión para comprimir los datos de un registro TLSPlainText. Esto es adicional antes que los datos sean encriptados, luego este texto plano se traslada a un registro comprimido llamado: TLSCompressed.

Figura No. 7.4 – Estructura de un texto plano y comprimido


10

Si al descomprimir, la longitud del fragmento supera los 2^14 bytes, se reporta un mensaje de Alerta de Error , llamado decompression_failure , el cual es fatal.

c) Protección del Registro:

Finalmente antes que los datos sean transmitidos por TCP, sucede la encriptación y autenticación de los mismos. Las funciones de encriptación y MAC definidas al inicio del estado de lectura y escritura de una conexión traducen la estructura TLSCompressed a TLSCipherText. Las funciones de desencriptación realizan el proceso inverso. El MAC del registro incluye también un número de secuencia para que los mensajes perdidos, extra o repetidos sean detectados.

Cuadro No. 7.3 – Cómo encriptan los dos algoritmos de encripción

El MAC es calculado antes de la encriptación, el cipher o algoritmo criptográfico encripta el bloque entero incluyendo el MAC.

7.2. El TLS Handshake Protocol: Este protocolo está compuesto de tres sub-protocolos4 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.

7.2.1. Propiedades de Handshake Protocol: a) La identidad de la otra parte puede ser verificada utilizando criptografía

asimétrica (RSA o DSS), esta autenticación puede ser opcional, pero generalmente se requiere por al menos una de las partes.

b) La negociación de un secreto compartido es segura: el secreto negociado no está

disponible para ningún atacante, incluso si el atacante utilizara un ataque hombre en el medio.

c) La negociación es confiable: ningún atacante puede modificar la comunicación sin

ser detectado por las partes que intervienen en la comunicación.

7.2.2. Subprotocolos de Handshake Protocol:

Para que un cliente y un servidor puedan empezar a comunicarse, ellos primero se ponen de acuerdo en la versión del protocolo, seleccionan los algoritmos criptográficos a usar, autenticarse (opcionalmente) uno con el otro, y usan técnicas de criptografía de clave pública para generar secretos compartidos. Para todo ello utiliza los siguientes subprotocolos:

4 SUBPROTOCOLOS DE HANDSHAKE: a) Change Cipher Spec Protocol, b) Alert Protocol, c) Handshake Protocol


11

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

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

c) Protocolo de mutuo acuerdo o handshaking:

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.

7.2.3. Secuencia de una conexión segura:

Cuadro No. 7.4 – Ítems requeridos para iniciar una sesión de Handshake


12

Figura No. 7.5 – Proceso de conexión segura usando SSL/TLS

A continuación una breve explicación del proceso de conexión segura vía Handshake: 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: la versión del protocolo usado, 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 tal. 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.


13

Cuadro No. 7.5 - Algoritmos de intercambio de clave soportados por TLS

A continuación del mensaje de Server Hello, el servidor puede enviar su Certificado (típicamente un X.509) de forma que sea autenticado por el cliente y que, además, 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 el 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. Durante la transmisión de datos los mensajes son fragmentados y comprimidos por el Record Protocol 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 hemos visto, en la fase de Handshake.

8. LA AUTENTICACION: El servicio de autenticación debe garantizar que una comunicación sea autentica. En el caso de un solo mensaje, tales como una señal de alarma o peligro, la función del servicio de autenticación es garantizar al receptor que el mensaje viene desde la fuente que el mensaje


14

dice que vino. En el caso de una interacción de mensajes, tal como una conexión TLS, el servicio abarca dos aspectos: a) En el momento de la iniciación de la conexión, el servicio garantiza que las dos entidades

son autenticas, esto es, que cada una es la entidad que esta dice que es. b) El servicio debe garantizar que la conexión no vaya a ser interferida de manera tal que una

tercer parte pueda camuflarse como una de las dos partes legitimas con el propósito de transmitir o recibir mensajes de forma no autorizada.

Con referencia al primer punto, otra cosa a tener en cuenta es que cuando hablamos de Internet o el protocolo TCP/IP, estamos hablando de una metodología de desarrollo de sistemas del tipo Cliente/Servidor. Cuando queremos establecer una conexión TLS, una de las partes actúa como servidor, brindando algún tipo de servicio. La otra parte actúa como un cliente, haciendo pedidos al servidor, para que luego este último retorne un resultado. La forma de autenticar las partes en una conexión cliente/servidor no es simétrica, sino que depende de si es el cliente quien quiere autenticar al servidor, o es el servidor quien quiere autenticar al cliente. Además, cuando se autentica un servidor, lo que se esta autenticando es la organización que es responsable por el servidor en el que corre el servicio, un una cierta dirección IP. Cuando se autentica un cliente, lo que se esta autenticando es el usuario que esta corriendo el programa cliente.

8.1. Tipos de Certificados:

a) Certificados de clientes TLS/SSL (*): Se usan para identificar clientes a los servidores vía TLS/SSL (autenticación de clientes).

b) Certificados de servidores TLS/SSL (*): Se usan para identificar servidores a los clientes vía TLS/SSL (autenticación de servidor).

c) Certificados S/MIME: Son usados para e-mail firmado y encriptado. Un simple certificado podría ser usado como un certificado S/MIME y un certificado TLS/SSL.

d) Certificados para firmar objetos: Se usan para identificar firmantes de código en Java, scripts en JavaScript, u otros archivos firmados.

e) Certificados de CA: Se usan para identificar entidades certificadores autorizadas como: Verisign, Identidata Holding, Alagraf, y ID Certify.

f) Los software cliente y servidor usan certificados de CA para determinar que otros certificados son confiables.

(*) "TLS/SSL" no significa que el nombre del certificado sea ese, sino que existen certificados de esos tipos tanto para SSL como para TLS. 8.2. Autenticación del Servidor:

El software cliente que requiera un servicio de un servidor, el cual se va a transferir a través de una conexión TLS, puede querer tener cierta validación criptográfica de la identidad del servidor, es decir que quiere autenticar que el servidor que envía la información es realmente quien dice que es. Para autenticar el enlace entre una clave pública y el servidor identificado por el certificado que contiene la clave pública, un cliente con capacidad para usar TLS (o SSL) debe recibir un "SI" por respuesta a cuatro preguntas a fin de poder autenticar la identidad del servidor. Aunque la cuarta pregunta técnicamente no es parte del protocolo TLS, es


15

responsabilidad del cliente soportar este requerimiento, el cual ofrece alguna garantía de la identidad del servidor y además ayuda a protegerse contra un tipo de ataque a la seguridad conocido como hombre en el medio. Las preguntas son:

a) La fecha de hoy esta dentro del período de validez del certificado? b) El CA emisor es un CA confiable? c) La clave pública del CA emisor valida la firma digital del servidor? d) El nombre de dominio especificado en el DN del servidor es igual a nombre de

dominio real? e) Si todo lo anterior está bien, el servidor es autenticado

Figura No. 8.1 – Autenticación del Servidor

8.3. Autenticación del Cliente:

Los servidores preparados para usar TLS pueden ser configurados para requerir que el cliente sea autenticado, para tener cierta garantía de la identidad del cliente. Cuando un servidor configurado de esta manera requiere autenticación del cliente, el cliente envía al servidor un certificado X.509 y separadamente envía también ciertos datos firmados digitalmente para autenticarse a sí mismo. El servidor usa los datos firmados digitalmente para validar la clave pública en el certificado y para autenticar la identidad que el certificado dice que representa. El protocolo TLS requiere que el cliente cree una firma digital a partir de datos generados aleatoriamente (conocidos solo por el cliente y el servidor), los cuales se les aplica una función de hashing (MD5 o SHA-1) durante el handshake. El hash de los datos luego se encripta con la clave privada que corresponde a la clave pública en el certificado presentado al servidor. Un servidor que usa TLS hace las siguientes preguntas para autenticar la identidad de un usuario:

a) La clave publica del usuario valida a su firma digital? b) La fecha de hoy esta dentro del período de validez? c) El CA emisor es un CA confiable? d) La clave pública del CA emisor valida la firma digital del cliente? e) El certificado del usuario esta listado en la entrada LDAP de ese usuario? f) El cliente autenticado esta autorizado para tener acceso a los recursos que requirió?


16

Figura No. 8.2 – Autenticación del Cliente

9. DIFERENCIAS ENTRE SSL y TLS: Como hemos dicho TLS se construye a partir de las especificaciones de SSL 3.0 y son tan semejantes que a TLS a veces se lo conoce como SSL 3.1. Los mismos autores dicen “[...] el protocolo TLS está basado en las especificaciones de SSL. Las diferencias entre este protocolo y SSL no son grandes, pero si suficientes para que TLS y SSL no puedan interoperar (aunque TLS incorpora un mecanismo mediante el cual una implementación de TLS puede trabajar con SSL 3.0)”. Las principales diferencias entre SSL 3.0 y TLS 1.1 son las siguientes: a) En los mensajes Certificate Request y Certificate Verify del protocolo de Handshake. En

SSL 3.0 si el servidor solicita un certificado al cliente para que se autentique, este debe de responder con el o con un mensaje de alerta advirtiendo de que no lo tiene. En TLS 1.1 si el cliente no posee certificado no responde al servidor de ninguna forma a este requerimiento.

b) Cálculo de las claves de sesión. El mecanismo utilizado para construir las claves de sesión es ligeramente diferente en TLS 1.1.

c) TLS 1.1 no soporta el algoritmo de cifrado simétrico FORTEZZA que si es soportado por SSL 3.0. Esto es debido a que TLS busca ser íntegramente público mientras que FORTEZZA es un algoritmo propietario.

d) TLS utiliza un mecanismo diferente y más seguro en el cálculo del MAC. e) TLS 1.1 introduce nuevos códigos de alerta no contemplados por SSL 3.0 f) TLS 1.1 introduce un nuevo mecanismo en el relleno de los bloques para frustrar ataques

basados en el análisis de la longitud de los mensajes. A la vez presenta varias mejoras y extensiones para: a) HTTP sobre el puerto 80 y HTTPS sobre el puerto 443 b) Nuevos Ciphersuites con cambios recientes en las regulaciones de exportación de US

permiten la exportación de software con capacidades de encriptación de datos con claves de 56 bits e intercambio de claves de hasta 1024 bits.

c) Soporte de Elliptic Curve Cryptosystems (ECC) con claves como: ECES (Elliptic Curve Encryption Scheme), ECDSA (Elliptic Curve Digital Signature Algorithm), ECNRA (Elliptic Curve Nyberg-Rueppel Signature Scheme with Appendix), ECDH (Elliptic


17

Curve Diffie-Hellman Key Agreement), ECMQV (Elliptic Curve Menezes-Qu-Vanstone Key Agreement).

d) Incorporación de Kerberos Cipher Suites, las credenciales Kerberos se usan para llevar a cabo una autenticación mutua y para establecer un master secret usado subsecuentemente para asegurar la comunicación cliente-servidor. La opción de Kerberos debe agregarse en el mensaje ClientKeyExchange.

e) Perfiles para Autorización usando Attribute Certificate, el X.509 AttributeCertificate provee una estructura con la cual se puede brindar tales servicios. Esta especificación define dos perfiles(uno simple y uno full) para el uso de X.509 AttributeCertificates al proveer los servicios de autorización.

10. APLICACIONES DE TLS: Es común pensar que TLS/SSL son protocolos utilizados sólo con los browsers para mostrar un Internet más seguro, sin embargo; estos son protocolos de propósito general que pueden ser usados para autenticación y protección, por ejemplo para: a) Transacciones seguras sobre sitios de e-commerce. b) Autenticación de clientes a un sitio Web seguro. c) Acceso Remoto. d) Acceso a Bases de Datos (SQL). e) Correo Electrónico. Respecto a los puntos a) y b) en el Cuadro No. 9.1, se detallan algunos ejemplos de navegadores que a la fecha soportan TLS/SSL. TLS/SSL se ejecuta en una capa entre los protocolos de aplicación como HTTP, SMTP, NNTP y sobre el protocolo de transporte TCP, que forma parte de la familia de protocolos TCP/IP. Aunque pueda proporcionar seguridad a cualquier protocolo que use conexiones de confianza (tal como TCP), se usa en la mayoría de los casos junto a HTTP para formar HTTPS. Por lo tanto HTTPS es usado para asegurar páginas Web para aplicaciones de comercio electrónico, utilizando certificados de clave pública para verificar la identidad de los extremos.

Cuadro No. 10.1 – Browsers que soportan SSL y TLS

Aunque un número creciente de productos clientes y servidores pueden proporcionar SSL/TLS de forma nativa, muchos aún no lo permiten. En estos casos, un usuario podría querer usar una aplicación SSL independiente como Stunnel para proporcionar cifrado. No obstante, el Internet Engineering Task Force recomendó en 1997 que los protocolos de aplicación ofrecieran un 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 – esto evitaría el uso de envolturas (wrappers) como Stunnel.


18

SSL/TLS también puede ser usado para tunelar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN. Como hemos visto, 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:

Cuadro No. 10.2 – Protocolos, Puertos seguros según la IANA NOTA: Estos puertos son válidos también para las implementaciones de estos mismos protocolos sobre TLS. 11. ESTANDARES RELACIONADOS CON TLS: Como sabemos la primera definición de TLS apareció en el RFC 2246, pero desde su publicación han aparecido muchas otras. A continuación se numeran algunas de las más actuales: a) RFC4934: Extensible Provisioning Protocol (EPP) Transport Over TCP. b) RFC4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport

Layer Security (TLS) c) RFC4681: TLS User Mapping Extension d) RFC4680: TLS Handshake Message for Supplemental Data e) RFC4642: Using Transport Layer Security (TLS) with Network News Transfer Protocol

(NNTP) f) RFC4572: Connection-Oriented Media Transport over the Transport Layer Security

(TLS) Protocol in the Session Description Protocol (SDP) g) RFC4513: Lightweight Directory Access Protocol (LDAP): Authentication Methods and

Security Mechanisms h) RFC4511: Lightweight Directory Access Protocol (LDAP): The Protocol i) RFC4507: Transport Layer Security (TLS) Session Resumption without Server-Side State j) RFC4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer

Security (TLS) k) RFC4366: Transport Layer Security (TLS) Extensions


19

l) RFC4346: The Transport Layer Security (TLS) Protocol Version 1.1 12. PROTOCOLO WTLS: El protocolo WTLS es una adaptación del estándar de Internet TLS (Transport Layer Security) y de los protocolos SSL. La intención de los autores de WTLS fue tomar TLS y añadir soporte a datagramas, optimizar el tamaño de los paquetes transmitidos y seleccionar algoritmos rápidos entre los permitidos. WAP ha definido WTLS siguiendo una serie de criterios: a) Debe soportar datagramas. b) Debe soportar portadoras de ancho de banda angosta. c) Debe soportar retardos potencialmente largos. d) La capacidad de memoria y procesamiento de los terminales puede ser pequeña. Si se utiliza WTLS para el envío de mensajes seguros ofrece los siguientes servicios: a) Integridad de los datos: Se asegura que los datos intercambiados entre el Terminal y la

pasarela WAP no han sido modificados. b) Confidencialidad de los datos: Se asegura que la información intercambiada entre el

terminal y la pasarela WAP no puede ser entendida por terceras partes que puedan interceptar el flujo de datos.

c) Autenticación: El protocolo contiene servicios para autenticar el terminal y la pasarela WAP.

d) Protección por denegación de servicio: Asegura que las capas superiores del protocolo WAP están protegidas contra ataques por denegación de servicios (DoS, Denial of Service) mediante la identificación y reenvío de los mensajes no comprobados.

El Foro WAP ha establecido tres tipos diferentes de seguridad, cada uno de ellos con sus requerimientos y características. En la tabla siguiente se muestran las especificaciones de seguridad y la relación que a nivel de capas de web y wap se manejan

Clases de Implementación de Seguridad TLS

Stacks de WEB y WAP

Cuadro No. 12.1 – Clases de Implementación de Seguridad TLS y Stacks de WEB y WAP


20

El hecho de que WTLS se ejecute en la cima de un inseguro servicio de datagrama, y no en un seguro protocolo de transporte como TCP/IP, obliga a realizar algunos ajustes para asegurar el intercambio de mensajes durante la realización de algunas operaciones WTLS. 13. CONCLUSIONES: Cada día muchas organizaciones están aprovechando las oportunidades ofrecidas por el comercio electrónico basado en Internet, y como hemos dicho el número va creciendo. Entre estas aplicaciones se encuentran las compras en línea, la banca electrónica, la tele-educación, los casinos virtuales, los servicios de pago por visión y vídeo bajo demanda, interconexión de extranets, intranets, etc. Si bien es cierto que existe una “seguridad certificada” por organismos que así lo aseguran, no es suficiente para que muchas empresas y más aún usuarios potenciales tengan recelo de utilizar estos beneficios “seguros”. Es indudable que no les falta razón, pues las aplicaciones de comercio electrónico, banca, etc; siempre han sido objeto de violaciones escandalosas de seguridad, pues el sólo hecho de tener sitios seguros, no es una garantía del 100% al menos en temas de seguridad. Como lo hemos evidenciado, al avance de la tecnología siempre se lo ha visto como una lucha entre el bien y el mal y que nunca terminará. Pues siempre el mal ha estado tratando de encontrar brechas por donde puede atacar y hacer daño a todo nivel. Está muy claro que el avance al menos en temas se seguridad como lo es SSL/TLS, muestran avances significativos, pero no suficientes ante la credibilidad del usuario, por ello es necesaria una mayor investigación en otras áreas relacionadas, como, la de las tarjetas inteligentes, ya que éstas serán el soporte básico en la utilización de la mayoría de las aplicaciones. Asimismo, será de vital importancia el desarrollo de nuevas técnicas de análisis de protocolos de seguridad, debido a que los protocolos orientados al comercio electrónico presentan características de eficiencia y escalabilidad opuestas a las de los tradicionales protocolos de seguridad, como los de intercambio de claves o los de autenticación de usuarios. En definitiva, queda aún mucho trabajo por desarrollar y muchas áreas que requieren un mayor grado de estudio antes de que el comercio electrónico pueda llegar a tener el nivel de implantación que se vislumbra, pero no cabe duda que el camino recorrido hasta momento es significativo y que la dirección parece ser la correcta. 14. TERMINOLOGIA • ALE (Automatic Link Establishment): Establecimiento automático de enlace. Técnica

que permite a las estaciones de radio enlazarse automáticamente unas con otras. • Ancho de banda: Tamaño de un canal de transmisión (ancho). Diferencia expresada en

hertzios (frecuencia) entre la frecuencia mas alta y la más baja de una banda. El ancho de banda define la capacidad máxima especificada de un canal de comunicación.

• ARP (Adresses Resolution Protocol): Este protocolo parte de conocer la dirección de red IP y averigua la dirección MAC.

• Arpanet: Red que estaba patrocinada por el Departamento de Defensa de los Estados Unidos. La Arpanet fue reemplazada y ampliada, y hoy sus descendientes forman la arteria principal de lo que llamamos la Internet.

• ASP (Aplication Service Provider): Proveedor de servicios relacionados con tecnologías de información y de comunicaciones. Utiliza diferentes tecnologías en banda ancha:


21

ADSL (Asymetric Digital Subscriber Line), WLL (Wireless Local Loop) y LMDS (Local Multipoint Distribution System), para crear redes públicas o privadas a través de tecnologías de seguridad.

• Comunicación de datos: Transmisión de datos entre estaciones de red. • DES: Estándar de Encriptación de Datos. Conocido sistema de criptografía de clave

secreta. El DES es un mecanismo de encriptación de datos muy utilizado y del cual existen varias implementaciones tanto en software como en hardware. El DES transforma información de texto llano en datos encriptados, llamado texto cifrado mediante un algoritmo especial y un valor semilla llamado clave. Si el receptor conoce la clave, puede usarla para convertir el texto cifrado en los datos originales.

• FTP (File Transfer Protocol): Provee la habilidad de enviar archivos de un host a otro, corre sobre TCP. Existen dos aspectos que hacen de FTP muy particular en su uso: su capacidad para transferir archivos entre computadores completamente distintos y su facilidad de compartir archivos públicos.

• Hacker: Término en inglés con el que se apoda a aquellas personas que, utilizando líneas telefónicas, intentan violar la integridad de un sistema o red de ordenadores, sin que sus usuarios lleguen a darse cuenta de ello, cometiendo así un delito.

• Hipertexto: En un texto clásico, la estructura es totalmente lineal: se lee de principio a fin; en un hipertexto, se pretende poder romper esa estructura lineal, mediante "enlaces" (también llamados "Vínculos" o "Hipervínculos") que permiten saltar a otros temas relacionados, donde encontrar información ampliada. Las páginas Web de Internet (como ésta) son un ejemplo claro de Hipertexto.

• HTML (HyperText Markup Language): El Lenguaje de marca de hipertexto, es un sistema para marcar o aportar información adicional a los documentos de forma que puedan publicarse en el World Wide Web. Los documentos preparados en HTML incluyen gráficos de referencia y marcas de formato. Utilice un explorador de Web (como Microsoft Internet Explorer, Netscape, etc.) para ver estos documentos. Es el lenguaje de descripción de páginas habitual en Internet.

• HTTP: El protocolo usado en las páginas del WWW (HyperText Transfer Protocol). • IMAP: Internet message access protocolo • IP (Internet Protocol): Es el protocolo que utiliza direcciones de 32 bits (4 octetos). Es

responsable de la transmisión de los datos en el nivel de red. Es en este nivel que sé enrutan los paquetes en función de las direcciones.

• IPSec: Internet Protocol Security. • RPC (Remote Procedure Call): Procedimiento de llamada remoto que conjuntamente con

XDR (Externa Data Representation) y NFS (Network File System) ejecutan funciones que corresponden aproximadamente a las capas Sesión, Presentación y Aplicación del modelo OSI, y se combinan para proveer acceso transparente a recursos de redes remotas.

• SCPC: Single Channel Per Carrier: Un sólo canal por operador. • SMTP (Simple Mail Transfer Protocol): Contiene los mecanismos para el intercambio de

correo electrónico entre máquinas, corre sobre TCP. • SNMP (Simple Network Managment Protocol): Una centralizada estación de

administración utiliza SNMP para obtener información de otros hosts y routers TCP/IP. SNMP define el formato para la data de administración y el tipo de intercambios que puede tomar lugar entre la estación de administración y otros dispositivos de la red.

• SSL: Capa de conexión segura (Secure Sockets Layer). • SSH (Secure Shell) • SSL (Secure Socket Layer) • TCP/IP: Nombre común aplicado a una familia de protocolos de comunicación de datos

que permiten conectar computadoras y redes. Los datos se transmiten en pequeños trozos


22

de información llamados paquetes. Es muy usado en Internet, como también en ambientes LAN y WAN por sus facilidades de enrutamiento.

• TLS (Transport Layer Secure) • Telnet: Es un protocolo de acceso de terminal remoto. Que corre sobre TCP. Permite a un

terminal atacharse a un servidor de terminales o a un host de comunicaciones. • WWW: World Wide Web: posiblemente, el servicio más conocido de Internet: una serie

de páginas de información, con texto, imágenes (a veces, incluso otras posibilidades, como sonido o secuencias de video), y enlazadas a su vez con otras páginas que tengan información relacionada con ellas.

15. REFERENCIAS

[1] http://www.ietf.org/ [2] http://en.wikipedia.org/wiki/Secure_Sockets_Layer [3] http://www21.ocn.ne.jp/~k-west/SSLandTLS/index-e.html [4] http://www.tecnun.es/ [5] http://technet2.microsoft.com/windowsserver/en/library/ [6] http://www-2.dc.uba.ar/materias/seginf/material/Clase13-Unidad5_5taparte_vf.pdf [7] http://www.iit.upcomillas.es/palacios/seguridad_dr/tema4_ssl.pdf [8] http://www.tejedoresdelweb.com/307/article-5670 [9] http://www.geocities.com/SiliconValley/Byte/4170/articulos/tls/index.htm [10] http://computacion.cs.cinvestav.mx/~jjangel/Pagina_Seguridad_Informacion_es.html [11] http://www.gwolf.org/seguridad/pki/node1.html [12] http://www.microsoft.com/spain/technet/recursos/articulos/11110308.aspx [13] http://internetng.dit.upm.es/ponencias-jing/2004/seguridad-en-web.pdf

* * *

transport layer security protocol - cybsec.com

Documents