PROTOCOLO SSL Y TLS

1 – Generalidades del protocolo SSL y TLS

1.1 – Posicionamiento de los protocolos SSL y TLS

SSL significa Secure Sockets Layer y su equivalente actual TLS significa Transport Layer Security. Ambos son protocolos situados entre el nivel de Transporte y el de Aplicación.

El SSL y el TLS se comportan como una capa intermedia adicional porque son independientes del protocolo utilizado en el nivel de aplicación. Esto significa que se puede utilizar para asegurar una transacción en la web, enviar o recibir correo electrónico, etc. Por consiguiente, el SSL y el TLS son transparentes para el usuario y no requieren el uso de protocolos específicos a nivel de aplicación.

1.2 – Objetivos y medios aplicados

SSL y TLS ofrecen las siguientes características :

  • Autenticación – El cliente debe ser capaz de verificar la identidad del servidor. Desde el SSL 3.0, el servidor también puede pedirle al cliente que se autentifique. Esta funcionalidad se proporciona mediante el uso de certificados.
  • Confidencialidad – El cliente y el servidor deben estar seguros de que su conversación no puede ser escuchada por un tercero. Esta funcionalidad es proporcionada por un algoritmo de encriptación.
  • Identificación e integridad – El cliente y el servidor deben ser capaces de asegurar que los mensajes transmitidos no sean truncados o modificados (integridad) y que provengan del remitente previsto. Estas características se aseguran mediante la firma de los datos.

Por lo tanto, el SSL y el TLS se basan en la combinación de varios conceptos criptográficos, explotando tanto el cifrado asimétrico como el simétrico.

También se pretende que el SSL y el TLS sean escalables, ya que el protocolo es independiente de los algoritmos de cifrado y autenticación utilizados en una transacción. Esto le permite adaptarse a las necesidades de los usuarios y a la legislación vigente. Esto también garantiza una mayor seguridad, ya que el protocolo no está sujeto a los avances teóricos de la criptografía (si un cifrado queda obsoleto, el protocolo sigue siendo utilizable al elegir un cifrado considerado seguro).

1.3 – Operación

Los protocolos SSL y TLS se dividen en dos capas principales (en realidad cuatro):

  • El protocolo de apretón de manos SSL y TLS elige la versión de SSL y TLS que se va a utilizar, realiza la autenticación mediante el intercambio de certificados y permite la negociación entre el cliente y el servidor de un nivel de seguridad mediante la elección de algoritmos de cifrado. Este es el protocolo utilizado para configurar la transacción.
  • El protocolo de registro SSL y TLS encapsula y fragmenta los datos. Es el protocolo de transmisión de datos.

En una primera fase, el cliente y el servidor llevarán a cabo la negociación para configurar la transacción e intercambiar las claves de cifrado. Entonces realizarán el intercambio de datos real.

1.4 – Esquema de este documento

Este documento presenta en primer lugar la evolución del SSL desde su creación hasta la aparición del actual protocolo TLS y sus diversas perspectivas de futuro. También sitúa al SSL en el contexto de las diversas soluciones existentes para asegurar las transacciones en la red. Luego recordaremos los conceptos criptográficos implementados. A continuación detallaremos el funcionamiento técnico de los protocolos SSL y TLS. Finalmente, discutiremos los límites de estos protocolos en términos de seguridad.

2 – Presentación de SSL y TLS

2.1 – Historia

Aquí está el historial de los protocolos SSL y TLS por versión de lanzamiento:

  • SSL 1.0
    • 1994
    • Netscape
  • SSL 2.0
    • Febrero de 1995
    • Netscape
    • El protocolo SSL versión 2.0
  • SSL 3.0
    • Noviembre de 1996
    • Netscape
    • El protocolo SSL versión 3.0
  • TLS 1.0
    • Enero de 1999
    • IETF
    • RFC 2246
  • Extensiones TLS
    • Junio de 2003
    • IETF
    • RFC 3546
  • Extensiones TLS
    • Abril de 2006
    • IETF
    • RFC 4366

2.2 – Perspectivas actuales

La primera versión de SSL fue desarrollada por Netscape Communications en 1994. El objetivo de Netscape era crear un canal seguro donde los datos pudieran pasar entre un cliente y un servidor, independientemente de la plataforma y el sistema operativo. Netscape también quería aprovechar los nuevos métodos de cifrado, como el AES (Advanced Encryption Standard), que había sustituido recientemente al cifrado DES (Data Encryption Standard).

Aunque originalmente el SSL estaba destinado únicamente a asegurar las transacciones entre un cliente y un servidor web (HTTP), la especificación se dio a conocer para que otros protocolos de nivel de aplicación pudieran explotarlo (FTP, Telnet, etc.). La especificación SSL 1.0 sólo se publicó internamente y ninguna aplicación será compatible con SSL 1.0.

Unos meses más tarde, en febrero de 1995, Netscape publicó la versión 2.0 del protocolo. Se implementa en la primera versión de su cliente web Navigator. El SSL 2.0 se basa en la autenticación del servidor por parte de la estación de trabajo del cliente y en el uso de un certificado de servidor en formato X.509 v3. Esta autenticación requiere, por parte del cliente, sólo cálculos de clave pública.

En noviembre de 1996, Netscape lanzó la versión 3.0 del protocolo. Comparado con SSL 2.0, SSL 3.0 ofrece además la posibilidad de que el servidor autentique al cliente. En este caso, el cliente debe poder utilizar su clave privada por una parte y por otra proporcionar su certificado en formato X.509 v3.

El IETF (Internet Engineering Task Force) ofrece a su vez un protocolo de transferencia segura basado en los conceptos de SSL, llamado TLS 1.0 (a veces llamado SSL 3.1) y descrito en RFC 2246. Compró la patente de Netscape sobre el protocolo SLL en 2001. Luego, en junio de 2003, se proponen extensiones para el TLS en forma de un nuevo RFC. El último RFC 4366, que actualiza el anterior, se publicó en abril de 2006.

Actualmente se utilizan los protocolos SSL 2.0, SSL 3.0 y TLS 1.0. Sin embargo, la versión 2.0 de SSL 2.0 tiene agujeros de seguridad conocidos.

2.3 – Contexto técnico

Como ya se ha mencionado, SSL y TLS son protocolos transparentes para el usuario, situados entre las capas de Aplicación y Transporte. Por lo tanto, muchos protocolos pueden explotar SSL y TLS, como HTTP (HTTPS), LDAP (LDAPS), etc.

Sin embargo, si bien el SSL y el TLS son transparentes a nivel de protocolo, no lo son a nivel de las aplicaciones que los utilizan. Por lo tanto, estos últimos requieren ajustes individuales para tener en cuenta el SSL y el TLS. Una de las debilidades de SSL y TLS es tener un número relativamente pequeño de implementaciones.

2.3.1 – Implementación de SSL y TLS

Implementación en los navegadores web
La mayoría de las implementaciones de SSL y TLS se encuentran en los navegadores y servidores web. El servidor Apache, en particular, puede aprovechar el SSL con una implementación basada en OpenSSL.
OpenSSL
Implementado en C, OpenSSL es un conjunto de herramientas de cifrado con dos bibliotecas (una de criptografía general y otra que implementa el protocolo SSL), así como un pedido en línea. OpenSSL soporta SSL 2.0, SSL 3.0 y TLS 1.0. OpenSSL se distribuye bajo una licencia similar a la de los Apaches.
GnuTLS
El proyecto GnuTLS propone una implementación del protocolo TLS que cumple con las especificaciones del IETF. GnuTLS soporta TLS 1.1, TLS 1.0, SSL 3.0 y extensiones TLS. Permite la autenticación a través de certificados X509 y PGP. A diferencia de OpenSSL, GnuTLS es compatible con las licencias GPL.

2.3.2 – Certificación

Como veremos en la presentación de los conceptos criptográficos, el principal riesgo asociado al uso de SSL y TLS es la apropiación indebida de certificados. A fin de evitar este riesgo, es importante que las autoridades de certificación validen o invaliden los certificados. Hay dos filosofías en conflicto.

Certificación X.509
La certificación X.509 se basa en el principio de las autoridades centralizadas, cuya función es mantener una lista actualizada de certificados válidos. También debe revocar los certificados vencidos, cuestionables, etc. El usuario se remite a esta autoridad cada vez que quiere comprobar la validez de un certificado. Estas autoridades están organizadas jerárquicamente, de modo que la más alta es la autoridad más confiable. La función de una autoridad superior es validar a las autoridades que dependen de ella.
Certificación PGP
La certificación PGP (Pretty Good Privacy) se basa en la filosofía «Los amigos de mis amigos son mis amigos». En efecto, la validez de los certificados se transmite de igual a igual: si un usuario valida o invalida un certificado, transmite la información a los usuarios con los que está directamente relacionado (por lo tanto, son usuarios de confianza). La certificación se transmite de un usuario a otro.
Los principales inconvenientes de la PGP son, por una parte, la dificultad de invalidar un certificado si ha sido reconocido previamente por muchos usuarios y, por otra parte, el problema de saber si las redes de confianza pueden ser suficientemente fiables.

Los protocolos SSL y TLS han elegido basarse en las certificaciones X.509.

2.3.3 – SSL y TLS en comparación con otras soluciones

Se utilizan otros protocolos para garantizar la seguridad de la red. Aunque ofrecen características que compiten con el SSL y el TLS, se consideran complementarios.

SSH
El SSH es un protocolo a nivel de aplicación que proporciona una alternativa segura a los servicios públicos tradicionales (rlogin, rsh, telnet) que no ofrecen confidencialidad. La capacidad de explotar un mecanismo de tunelización hace que SSH, como SSL y TLS, sea compatible con otros protocolos de nivel de aplicación existentes. Al igual que SSL y TLS, SSH proporciona autenticación de la máquina, confidencialidad e integridad de los datos. También proporciona la autenticación de la contraseña de los usuarios.
El SSH sufre de debilidades en comparación con el SSL y el TLS: no integra la noción de certificados X509 v3, requiere la instalación de una aplicación cliente específica (no hay transparencia), y la noción de túnel sigue siendo difícil de comprender.
Sin embargo, el SSH es menos vulnerable que el SSL y el TLS en cuanto a la identificación del cliente. De hecho, la protección del certificado en la estación de trabajo de un cliente no siempre se puede garantizar adecuadamente.
IPSec
El IPSec proporciona un mecanismo de seguridad a nivel de la capa de red (IP). Se utiliza en particular para la implementación de redes privadas virtuales (VPN). Las funcionalidades del IPSec son la autenticación de la máquina, la confidencialidad y la integridad de las transacciones.
Su inseparable implementación de la próxima versión del protocolo IP, IPv6, compite con las funcionalidades de confidencialidad e integridad de SSL y TLS. Además, proporciona seguridad para toda la red en lugar de para las aplicaciones individuales en cada caso.
Por lo tanto, hasta la fecha, las características de seguridad del IPSec e IPv6 se consideran un complemento importante de la seguridad que ofrecen el SSL y el TLS.
SET/3D-Secure
Basados en SSL y TLS, los protocolos SET (ahora obsoleto) y 3D-Secure ofrecen una autenticación validada por un tercero. Estos protocolos están destinados principalmente a aplicaciones de pago en línea (son desarrollados por instituciones bancarias). Mientras que SSL y TLS y SET/3D-Secure aseguran cada uno un alto grado de confidencialidad, sólo SET permite una identificación mutua completa de ambas partes gracias a un tercero de confianza, en este caso el banco del vendedor. De esta manera, asegura al vendedor que la tarjeta es buena y no ha sido robada y al cliente que no se hará un uso malicioso de esta información.
Podemos ver aquí que, aunque sufre limitaciones, el universo SSL y TLS es vasto y estable.

2.4 – Puertos y aplicaciones que utilizan SSL y TLS

Aquí está la lista de aplicaciones que usan SSL y TLS con sus puertos TCP asociados:

  • Protocolo: NSIIOPS
    • Puerto TCP: 261
    • Descripción: Servicio de Nombres del IIOP sobre SSL y TLS
  • Protocolo: HTTPS
    • Puerto TCP: 443
    • Descripción: HTTP sobre SSL y TLS
  • Protocolo: DDM-SSL
    • Puerto TCP: 448
    • Descripción: DDM-SSL
  • Protocolo: SMTPS
    • Puerto TCP: 465
    • Descripción: SMTP sobre SSL y TLS
  • Protocolo: NNTPS
    • Puerto TCP: 563
    • Descripción : NNTP sobre SSL y TLS
  • Protocolo: SSHELL
    • Puerto TCP: 614
    • Descripción: SSL Shell
  • Protocolo: LDAPS
    • Puerto TCP: 636
    • Descripción: LDAP sobre SSL y TLS
  • Protocolo: FTPS-DATA
    • Puerto TCP: 989
    • Descripción: Datos FTP sobre SSL y TLS
  • Protocolo: FTPS
    • Puerto TCP: 990
    • Descripción : Control de FTP sobre SSL y TLS
  • Protocolo: TELECOMUNICACIONES
    • Puerto TCP: 992
    • Descripción : Telnet sobre SSL y TLS
  • Protocolo: IMAPS
    • Puerto TCP: 993
    • Descripción : IMAP4 sobre SSL y TLS
  • Protocolo: IRCS
    • Puerto TCP: 994
    • Descripción: IRC sobre SSL y TLS
  • Protocolo: POP3S
    • Puerto TCP: 995
    • Descripción : POP3 sobre SSL y TLS

3 – Aspectos criptográficos

Los conceptos implementados en SSL y TLS se basan en conceptos criptográficos comunes. SSL y TLS utiliza métodos de cifrado simétricos y asimétricos para asegurar sus diversas funciones: autenticación, firma, integridad e identificación.

Sin entrar en los algoritmos utilizados, es sin embargo interesante observar las bases criptográficas que dieron lugar a los protocolos.

Matemáticamente, los protocolos de intercambio de mensajes, llamados criptosistemas, se representan como una quíntuple

M representa el conjunto de mensajes claros
C todos los mensajes codificados
K todas las llaves
E el conjunto de funciones de cifrado (es decir, un conjunto de la forma :

D el conjunto de funciones de desencriptación (es decir, un conjunto de la forma :

3.1 – Encriptación de clave simétrica o secreta

El cifrado simétrico, también conocido como cifrado de clave secreta, es la forma más antigua de cifrado. Consiste en utilizar un valor corto (la clave) para hacer que un mensaje sea ininteligible para terceros.

Se dice que es simétrica porque esta misma clave permite a quienes la conocen descifrar el mensaje y así acceder a su contenido.

Matemáticamente, una clave secreta del criptosistema es por lo tanto negada por la condición:

En lo que respecta a la aplicación de un protocolo de seguridad, el cifrado simétrico es interesante porque es sencillo de aplicar y requiere poco tiempo de computación. Valida la restricción de confidencialidad, siempre y cuando la llave permanezca secreta.

Sin embargo, tiene un gran inconveniente: la dificultad de proteger el secreto de una llave. En efecto, en el momento en que ambas partes intercambian su clave secreta, no pueden asegurarse de que no sea interceptada por un tercero. Por lo tanto, esta solución por sí sola es insuficiente.

3.2 – Encriptación asimétrica o clave pública

3.2.1 – Cifrado

El cifrado asimétrico, también conocido como cifrado de clave pública, proviene de descubrimientos teóricos relativamente recientes en el campo de las matemáticas. Se basa en la existencia de funciones matemáticas que son difíciles de revertir, excepto explotando una brecha secreta.

La clave del criptosistema es aquí una pareja (kprivate, kpublic). kprivate es conocido sólo por el destinatario de los mensajes y kpublic es universalmente conocido.

Las funciones de codificación y descodificación se convierten entonces en ekpublic, dkpublic y kprivate respectivamente, es decir, es posible codificar un mensaje, pero sólo el titular de la clave privada (el destinatario del mensaje) puede descodificarlo.

Por lo tanto, se denomina asimétrico, porque es fácil para cualquier usuario codificar un mensaje, pero difícil de decodificar. La encriptación asimétrica permite, por lo tanto, asegurar la identidad del receptor.

3.2.2 – Firma

La firma asegura la identidad del remitente de un mensaje. Los métodos de firma utilizan en realidad un protocolo que es el reverso del protocolo de cifrado.

El remitente encriptará un mensaje dado con su clave privada. Sólo el remitente puede hacer esto. Por otra parte, cualquiera puede verificar que el mensaje ha sido cifrado por el remitente, descodificándolo con la clave pública y comprobando que corresponde al mensaje original.

De hecho, se utiliza una función de violación secreta para la firma, como..:

Dado que sólo el remitente previsto conoce d(), el destinatario puede asegurarse de que la comunicación recibida se compruebe que :

Sin embargo, aunque este proceso identifica al remitente, tiene la desventaja de que hace que el mensaje transmitido sea descifrable por todos.

3.2.3 – Una primera limitación

Por lo tanto, es teóricamente posible utilizar una pila de dos criptosistemas, uno de firma de clave pública, el otro de cifrado de clave pública: de esta manera, las dos partes se identifican entre sí, conociendo cada una la clave pública de su interlocutor.

Sin embargo, los algoritmos de clave secreta requieren muchos recursos, tanto para el cifrado como para el descifrado, por lo que esta solución no pudo adoptarse en los protocolos SSL y TLS. Por consiguiente, la codificación asimétrica se asoció a los pasos críticos del protocolo: el intercambio de claves secretas, que permite el uso seguro de la codificación simétrica (mucho más ligera) y, de forma más ligera, la verificación de la firma y la integridad de los datos.

3.2.4 – Firma y hashing

El principio de verificación de la firma y la integridad se simplifica mediante el uso previo de una función de hachís. Una función de hash calcula el resumen de un texto. Este resumen debe ser unidireccional, para evitar reconstruir el mensaje inicial conociendo sólo el resumen. Debe ser muy sensible, es decir, un pequeño cambio en el mensaje lleva a un gran cambio en el resumen. Enviando un mensaje con su resumen (también llamado su hash), se puede asegurar la integridad del mensaje recalculando el resumen a su llegada.

Al asociar el hash y la firma, es posible asegurar las funcionalidades de control de integridad e identificación del remitente de una manera simple y eficiente. La firma se hace fácil de calcular (porque el hash es mucho más corto que el mensaje), y su integridad, así como la del mensaje, se vuelven interdependientes. Este es el proceso que se utilizará en SSL y TLS, bajo el nombre de MAC signature.

3.3 – Aparición de la noción de certificación

3.3.1 – Ataque desde el centro

Sin embargo, sigue existiendo un problema: la fiabilidad del sistema descrito depende de la confianza depositada en las claves públicas. Las propias claves públicas deben darse a conocer a los participantes en una transacción. Así pues, la seguridad se ve menoscabada si un tercero malintencionado puede difundir claves públicas falsificadas sin el conocimiento de los participantes.

Caso normal

  • 1 – Alice y Bob intercambian su llave pública. Charles puede leerlos, así que conoce kapublic y kbpublic.
  • 2 – Si Alice quiere enviar un mensaje a Bob, lo encripta con kbpublic. Bob lo descifra con Kbprivate.
  • 3 – Charles, que sólo tiene kbpublic, no puede leer el mensaje.

Ataque, Ahora supongamos que Charles es capaz de modificar los intercambios entre Alice y Bob.

  • 1 – Bob envía su llave pública a Alice. Charles lo intercepta y envía su propia llave pública a Alice haciéndose pasar por Bob.
  • 2 – Cuando Alice quiere enviar un mensaje a Bob, sin saberlo usa la llave de Charles.
  • 3 – Alice encripta el mensaje con la clave pública de Charles y lo envía a la persona que cree que es Bob.
  • 4 – Charles intercepta el mensaje, lo descifra con su clave privada kcprivate y puede leer el mensaje.
  • 5 – Luego encripta el mensaje de nuevo con la clave pública de Bob kbpublic, después de modificarla posiblemente.
  • 6 – Bob descifra su mensaje con su clave privada y no sospecha nada ya que funciona.

Así, Alicia y Bob son persuadidos a usar la llave del otro, cuando en realidad ambos usan la llave de Charles.

3.3.2 – Protección contra el ataque desde el centro

Hay varias maneras de protegerse contra este ataque. Los dos principales son el método de la red de confianza, el método de certificación de terceros de confianza. También hay métodos de intercambio directo (mano a mano, teléfono) y de autenticación de contraseñas.

3.3.3 – Certificación X.509

El principio de certificación por una autoridad se basa en la confianza de los organismos centrales. La entidad que desea obtener una certificación se dirige a una autoridad, proporcionándole su clave pública. La autoridad, tras verificar la identidad del solicitante, le proporcionará un certificado al que adjuntará su propia firma: esta firma permite entonces asegurarse de que el certificado ha sido efectivamente expedido por una autoridad competente.

El organismo de certificación actúa entonces como un tercero de confianza. El protocolo utilizado para la certificación bajo SSL y TLS es X.509 v3.

Los certificados raíz (es decir, los certificados emitidos por autoridades altamente viables) se implementan directamente en los navegadores web. El problema en este momento sigue siendo principalmente la falta de actualización de los certificados en caso de compromiso (de la clave privada, por ejemplo).

Estructura de un certificado X.509

  • Versión
  • Número de serie
  • Algoritmo de firma de certificados
  • Firmante del certificado
  • Validez (plazos)
    • No hasta que
    • No después de
  • El titular del certificado
  • Información de clave pública
    • Algoritmo de clave pública
    • Clave pública
  • Identificador único del firmante (Opcional)
  • Identificador único del titular del certificado (Opcional)
  • Extensiones (Opcional)
    • Lista de extensiones…

4 – Los protocolos SSL y TLS

Los protocolos SSL y TLS se subdividen en cuatro subprotocolos:

  • Protocolo de apretón de manos – Este protocolo negocia los parámetros de encriptación que estarán en funcionamiento durante la conexión.
  • Protocolo de Cambio de Códigos Específicos – Este protocolo anuncia el final del protocolo de negociación.
  • Protocolo de Alarma – Este es el protocolo para reportar errores y alertas.
  • Protocolo de registro – Este protocolo se encuentra entre los otros y la Capa 4 y es el protocolo de comunicación para SSL y TLS.
  • Están organizados como se muestra en el siguiente diagrama:

Empecemos con el protocolo de negociación, porque es el primero que se utiliza.

4.1 – El protocolo Hanshake

Permite al cliente y al servidor autenticarse mutuamente, negociar los algoritmos de encriptación, negociar los algoritmos MAC (Código de Autenticación de Mensajes) y finalmente negociar las claves simétricas que se utilizarán para la encriptación.

4.1.1 – Formato de intercambio

Cada mensaje intercambiado entre el cliente y el servidor contiene tres campos:

  • Tipo – indica el asunto del mensaje (1 byte)
  • Longitud – indica la longitud del mensaje (3 bytes)
  • Contenido – contiene los datos transmitidos (más de un byte)

4.1.2 – Detalle de los intercambios

1 – El cliente envía un mensaje HELLO_CLIENT, en texto claro, al servidor. Este mensaje contiene..:

  • Versión – La versión más alta de SSL que el cliente puede usar.
  • Aleatorio – Una marca de tiempo de 32 bits y un valor aleatorio de 28 bytes generado por el cliente. El número resultante se utilizará para firmar los mensajes.
  • Identificación de la sesión – Un número, que identifica la conexión. Un cero significa que el cliente está dispuesto a establecer una nueva conexión en una nueva sesión. Otro número significa que el cliente está dispuesto a cambiar la configuración o crear una nueva conexión en la sesión existente.
  • CipherSuite – Una lista, en orden descendente de preferencia, de los algoritmos que el cliente soporta. Estos son los algoritmos de intercambio de claves y de encriptación.
  • Método de compresión – Una lista, en orden descendente de preferencia, de los algoritmos de compresión soportados por el cliente.
  • Entonces el cliente espera una respuesta del servidor

2 – El servidor responde al cliente en texto claro: HELLO_SERVER. El mensaje contiene..:

  • Versión – La versión más alta de SSL que el cliente puede usar.
  • Aleatorio – Una marca de tiempo de 32 bits y un valor aleatorio de 28 bytes generado por el cliente.
  • ID de la sesión – El identificador de la sesión que se está iniciando.
  • CipherSuite – La secuencia de algoritmos elegidos para la sesión. El servidor selecciona la primera secuencia que conoce de la lista transmitida por el cliente.
  • Método de compresión – El método de compresión que se utilizará.
  • Ahora que los algoritmos han sido elegidos, el servidor se autenticará ante el cliente. Envía su(s) certificado(s) (X.509) al cliente. En esta etapa puede solicitar un certificado al cliente. El cliente verifica la autenticidad del servidor: si se cuestiona esta autenticidad, la transacción se interrumpe.

3 – Generación de claves de encriptación simétrica. El cliente genera a su lado una pre-llave que será utilizada para producir las llaves que se usarán después. Esta clave se envía al servidor, cifrada con su clave pública. Usando esta pre-clave, el servidor y el cliente generan cuatro claves para la sesión:

  • El servidor escribe el secreto de los macs, usado para firmar los mensajes del servidor.
  • El cliente escribe el secreto de Mac… para los mensajes del cliente.
  • Clave de escritura del servidor – para encriptar los datos enviados por el servidor.
  • La clave de escritura del cliente… para el cliente.
  • Estas llaves no se intercambian. Si es necesario, el servidor comprueba la autenticidad del cliente.

4 – El cliente envía el mensaje CLIENT_FINISHED al servidor. Este mensaje está encriptado y firmado con las claves anteriores. Esto significa que a partir de ahora, el cliente se comunica de esta manera.

5 – El servidor hace lo mismo. Estos mensajes se denotan por el sub-protocolo Change Cipher Spec (esto es todo lo que este protocolo define).

4.2 – El protocolo Change Cipher Spec

Este registro contiene un solo mensaje: change_cipher_spec. Es enviado por ambas partes al final del registro de la negociación. Este mensaje transita encriptado por el algoritmo simétrico previamente negociado.

4.3 – El protocolo de alarma

Este registro especifica los mensajes de error que los clientes y los servidores pueden enviarse entre sí. Los mensajes son de dos bytes de largo. La primera es de advertencia o fatal. Si el nivel es fatal, la conexión se aborta. No se cortan otras conexiones en la misma sesión, pero no se pueden establecer otras nuevas. El segundo byte da el código de error.

Los errores fatales son..:

  • Unexpected_message – indica que el mensaje no fue reconocido.
  • Bad_record_mac – reporta una firma MAC incorrecta
  • Descompresión_fallo – indica que la función de descompresión recibió una entrada incorrecta
  • Handshake_failure – imposible negociar los parámetros correctos
  • Parámetro_ilegal – indica un campo mal formateado o un campo que no coincide con nada.

Las advertencias son..:

  • Close_notify – anuncia el fin de una conexión.
  • No_certificado – responde a una solicitud de certificado si no hay certificado disponible
  • Certificado_malo – el certificado recibido no es bueno (por ejemplo, su firma no es válida)
  • Unsupported_certificate – el certificado recibido no es reconocido
  • Certificate_revoked – certificado revocado por el emisor
  • Certificado_expirado – certificado expirado
  • Certificado_desconocido – para cualquier problema con los certificados no enumerados anteriormente.

4.4 – El protocolo de registro

Este protocolo anula los otros protocolos SSL y TLS, proporcionando una interfaz unificada para la transmisión de datos.

4.4.1 – Papel

  • Encapsulación – Permite que los datos SSL y TLS se transmitan y reconozcan de forma consistente.
  • Confidencialidad – Garantiza que el contenido del mensaje no pueda ser leído por un tercero: los datos se cifran utilizando las claves producidas durante la negociación.
  • Integridad e identidad – Verifica la validez de los datos transmitidos, gracias a las firmas MAC: esta firma también se genera con las claves producidas durante la negociación.

4.4.2 – Proceso de encapsulación

Segmentación – Los datos se desglosan en bloques más pequeños 16.384 bytes
Compresión – Los datos se comprimen utilizando el algoritmo elegido durante la negociación. A partir de SSL 3.0, no hay más compresión.
Firma MAC (0, 16 o 20 bytes) – Se genera una firma de los datos utilizando la clave MAC. Dado que utiliza una función de condensación, en realidad se denomina HMAC (Hashed MAC). Se calcula de la siguiente manera:

HASH(
        write mac secret
        | pad_2
        | HASH(
                  write mac secret
                  | pad_1
                  | numéro de ce message
                  | protocole pour ce message
                  | longueur de ce message
                  | données compressées
                  )
        )

La función de condensación de HASH() es MD5 o SHA-1.

Pad_1 y pad_2 son palabras de relleno (pad_1 = 0x36 y pad_2 = 0x5C (repetidas 40 veces para SHA-1 y 48 veces para MD5))

  • Encriptación – El paquete resultante se encripta usando la función definida durante la negociación y la clave de escritura. Los algoritmos posibles actualmente para la encriptación son 3-DES 168, IDEA 128, RC4 128, Fortezza 80, DES 56, DES-40, RC4-40, RC2-40.
    • Añadir encabezado (5 bytes) – Se añade el encabezado SSL y el paquete se pasa a la capa inferior. Contiene..:
      • Tipo de contenido (1 byte) – Indica el tipo de paquete SSL y TLS contenido en el registro :
        • 0x20 – Especificación de cifrado de cambio de tipo de paquete
        • 0x21 – Paquete de tipo de alerta
        • 0x22 – Paquete de tipo apretón de manos
        • 0x23 – Paquete de datos de aplicación: este tipo corresponde a los datos reales de la transacción SSL.
  • Versión Mayor (1 byte), Versión Menor (1 byte) – Números de versión primarios y secundarios del protocolo SSL y TLS utilizados. Por ejemplo, el protocolo TLS1.0 se identificará con el par (0x03.0x01), porque TLS 1.0 se considera la versión 3.1 de SSL.

Longitud (Comprimida) (2 bytes) – El tamaño (comprimido si es aplicable) del fragmento SSL y TLS.

4.4.3 – Recepción de paquetes

Cuando se reciben los paquetes, el receptor realiza las siguientes operaciones:

  • 1 – Verificación del encabezado SSL
  • 2 – Romper el paquete
  • 3 – Verificación del campo HMAC (aplicando la misma función de arriba a los datos desencriptados y comparando el resultado con el HMAC recibido)
  • 4 – Descompresión de los datos
  • 5 – Reensamblar las partes

Si durante estas comprobaciones algo sale mal, se genera una alarma.

5 – Debilidades y posibles ataques

5.1 – Limitaciones

Los navegadores no tienen características avanzadas de gestión de claves: por ejemplo, los certificados no se pueden renovar automáticamente y no se guarda el historial de claves. Cuando un certificado expira, el usuario recibe un mensaje y debe obtener manualmente un nuevo certificado, lo que no es necesariamente trivial para un usuario normal.

La relación de confianza es negada por la lista preinstalada de Autoridades de Certificación: los navegadores comerciales vienen con muchas claves públicas preinstaladas (Netscape tiene 33). Se utilizan para verificar la firma de la autoridad de certificación para los certificados de otros navegadores o servidores. Para ser confirmado, un certificado debe ser firmado por cualquiera de las autoridades presentes en el navegador. Por lo tanto, si alguno de los CA certifica un sitio fraudulento, este certificado será verificado correctamente por millones de navegadores.

Este problema es especialmente grave cuando se trata de certificados revocados. Los protocolos SSL y TLS (1.0) no requieren que la autoridad de certificación obtenga la Lista de Certificados Revocados (CRL) antes de utilizar un certificado (o periódicamente). Un certificado así firmado por una autoridad puede ser revocado (uso fraudulento del certificado, clave divulgada…) sin que el usuario sea informado.

Podemos entonces imaginar el siguiente ataque:

5.2 – Un escenario de ataque

Un usuario malintencionado puede crear un sitio con un nombre similar a otro, conocido, por ejemplo, www.goggle.com. Este usuario obtiene entonces un certificado para su sitio y puede atrapar a otros usuarios mediante la pesca u otros medios. En este caso, aunque la autoridad revoque el certificado, el sitio pirata seguirá siendo percibido como seguro por los navegadores web.

6 – Conclusión

Las características del SSL son, por lo tanto, :

  • Independencia de las capas inferiores y superiores
  • Operación en modo cliente/servidor
  • Garantía para ambas partes de una transacción autenticada (certificados), privada (cifrado), identificada e integridad (MAC).

La edad del SSL le da una cierta madurez y una larga experiencia. A pesar de sus fallas a nivel de autenticación, su uso es generalizado y esto demuestra su robustez. Su escalabilidad y su evolución le prometen un futuro brillante.

Categorías Red

Deja un comentario