El Cifrado Web (SSL/TLS) ¿Cómo funciona?

Hace ya tiempo expliqué cómo navegar por internet de manera segura y en esa entrada hablé de las conexiones seguras https. Ahora me dispongo a explicar cómo funcionan dichas conexiones seguras con el fin de mejorar el entendimiento de las mismas y colateralmente aumentar nuestra seguridad al navegar.

Por qué es necesario?

Siempre que usamos el navegador y nos conectamos a una web nos exponemos a que dicha conexión no sea segura, esto implica que los datos que estamos transmitiendo (por ejemplo nuestro usuario y contraseña) se envíen en texto plano y al final esto se traduce en que alguien con un analizador de trafico de red cómo por ejemplo Wireshark sea capaz de ver dichos datos y robarlos.

wireshark_http_example
Ejemplo de paquete interceptado con Wireshark

En la captura podemos ver un ejemplo de transmisión interceptada por Wireshark sobre una conexión no segura (http).

El cifrado paso a paso

La solución pasa por realizar una conexión cifrada (segura) mediante el uso de https.

Este cifrado tiene su origen en la criptografía asimétrica y por tanto debemos tener dos claves

  1. La clave publica
  2. La clave privada

La clave publica es la que se utiliza para encriptar la información saliente y dicha información solo puede ser desencriptada usando la clave privada. Si por algún casual alguien intentase desencriptar el paquete con la clave publica lo que haría es obtener un paquete totalmente ininteligible y no le serviría para nada.

Una vez claro el concepto de clave publica y privada, vamos a ver el esquema de funcionamiento de la conexión segura (imagen sacada de OVH)

  1. schema_ssl_subsSolicitud de establecimiento de una conexión segura por SSL
  2. Presentación del certificado y comprobaciones realizadas en el certificado en esta fase:
    – Validez
    – Firma por un tercero de confianza
    – Transmision de las versiones del protocolo y cipher suit soportados
  3. Transmisión de una clave de encriptación única (codificada con la clave pública del servidor) después de haber concretado la versión del protocolo y el cipher suite
  4. Desencriptado de la clave de encriptación por el servidor utilizando su clave privada
    – Establecimiento de la conexión segura

 

 

 

 

 

¿Por qué necesitamos un certificado firmado por un tercero de confianza?

La conexión segura nos certifica que entre el ordenador del cliente y el servidor se transmite la información de manera cifrada pero, ¿qué pasaría si el servidor en realidad fuese de un atacante en vez del real?

Si a causa de un ataque mediante técnicas man in the middle sucediese esto, la información se enviaría cifrada al atacante y no nos la podría robar nadie salvo el destinatario pero el atacante si que nos la robaría ya que el sería el atacante por tanto es de vital importancia saber que al servidor al que nos estamos conectando es el correcto y esto nos lo asegura este tercero de confianza. Una entidad que certifica que la empresa es quien dice ser.

Nuestro navegador comprobará que el emisor, la entidad de confianza que ha emitido el certificado, sea de fiar mirando la lista de autoridades validas.

CIFRADO_3
Listado de autoridades emisoras de certificados que nuestro navegador tiene instalada

¿Cómo se si estoy usando una conexión segura SSL/TLS?

Para verificar el certificado debemos realizar los pasos de la siguiente imagen y sobretodo ante la duda mejor asegurar y desconectarnos de la web.

CIFRADO_5

¿Es 100% segura la conexión bajo SSL/TLS?

Espero que a estas alturas todo ya os imaginéis que no hay nada seguro y menos en el mundo de la informática. Cada día salen nuevos agujeros de seguridad y poco a poco se van solucionando (conforme se van sabiendo)  pero siempre hay alguien intentando probar los limites de la tecnología y a veces se descubren nuevos bugs (ver Heartbleed).

Ejemplo 1: ataque Heartbleed
CIFRADO_4
Ejemplo 2: ataque en versiones antiguas del protocolo SSL

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Si un atacante robara el certificado con la clave privada de un servidor, podría crear un servidor falso al cual podríamos acceder y entregar sin saberlo todos nuestros datos. Un paso más allá sería que si la clave privada de un CA (Certificate Authority) fuera robada, el ladrón podría crear y firmar certificados falsos para cualquier dominio y hacer que los usuarios se conectasen a servidores falsos sin que se den cuenta.

Por último añadir que al implementar HTTPS en una página Web podemos afirmar que estamos transmitiendo más datos que si se utilizara HTTP. El volumen de tráfico es mayor y se ralentiza la Web al tener que realizar el cifrado. ¿Por qué no usar HTTPS sólo en la página de acceso para introducir los datos del usuario? El usuario y contraseña irían cifrados pero, ¿qué pasaría con las cookies? Si las cookies van en texto plano, cifrar el usuario y la contraseña no vale de nada.

SSL vs TLS. Cual uso? Qué es mejor?

SSL y TLS van ligados muy de cerca ya que son las versiones del sistema de conexiones seguras.

  • SSL 1.0  Esta versión nunca se llego a hacer publica
  • SSL 2.0 Esta versión se presentó en febrero de 1995 pero contenía una cantidad de fallas de seguridad que al final llevaron al diseño de la versión SSL 3.0
  • SSL 3.0 Esta versión se publico en 1996
  • TLS 1.0 Esta versión fue definida en el RFC 2246 en enero de 1999 y es una actualización de SSL versión 3.0.
  • TLS 1.1 Esta versión fue definida en el RFC 4346 en abril de 2006 y es una actualización de TLS 1.0.
  • TLS 1.2 Esta versión fue definida en el RFC 5246 en agosto del 2008. Se basa en una especificación posterior de TLS 1.1
  • TLS 1.3 (borrador) Hasta mayo de 2015, TLS 1.3 es un borrador, y los detalles no se han fijado todavía. Se basa en la especificación anterior TLS 1.1 y 1.2

Si el servidor está configurado correctamente y utiliza las versiones más recientes de TLS evitará los ataques ya descubiertos y minimizan riesgos. Desafortunadamente, hoy en día la mayoría de los sitios web no utilizan las nuevas versiones de TLS. Compruebe cómo está configurado su sitio.

Las diferencias entre SSL y TLS son en las dos formas distintas en que un programa puede iniciar una conexión segura:

  1. Por puerto (SSL), conexión a puerto específico significa que se debe utilizar una conexión segura. Por ejemplo, el puerto 443 para https (web segura), 993 para IAMP seguro, 995 para POP seguro, etc. Estos puertos se configuran en el servidor dispuestos a interactuar en una conexión segura en primer lugar, y hacer el resto de las funcionalidades de tu programa en segundo lugar.
  2. Por protocolo (TLS). Estas conexiones primero comienzan con un inseguro “hola” al servidor. Entonces solo cambia a una comunicación segura luego de un acuerdo entre el cliente y el servidor. Si este acuerdo falla por alguna razón, se corta la conexión.

Así pues a la pregunta de cual usaremos esta claro que el mas nuevo, pero ¿lo elegimos nosotros? NO!! Esto se elige de manera automática mediante una negociación entre el cliente y el servidor dando prioridad al protocolo que más nos favorezca es decir al más nuevo.

Funcionamiento avanzado del protocolo TLS

Si abrimos el certificado de una conexión segura veremos una imagen parecida a la que tenemos debajo

cipherPrimero tenemos el protocol que no es más que el protocolo que estamos usando para la transmisión de los datos de manera segura.

A continuación tenemos el Key Exchange que no otra cosa que el algoritmo que usamos para generar el par de claves publica y privada.

Por ultimo tenemos el Cipher Suite que es el algoritmo que hemos usado para generar la clave única de encriptación.

El algoritmo RSA se invento en 1977 por Ron Rivest, Adi Shamir y Len Adleman del MIT (de ahí las siglas de su nombre) y da solución a la generación de claves asimétricas para procesos de clave publica y privada usando el producto de números primos. Mientras que para algoritmos simétricos se considera segura una clave de 128 bits, para la mayoría de algoritmos asimétricos (incluido el del RSA) se recomiendan actualmente claves de al menos 1024 bits de longitud (google utiliza claves de 2048 bits). Actualmente es el algoritmo más extendido para esta práctica.

Se cree que RSA será seguro mientras no se conozcan formas rápidas de descomponer un número grande en producto de primos (véase computación cuántica).

¿Por qué no se utiliza esta algoritmo para cifrar todo el trafico en vez de solo la clave final de encriptación?

Por un problema de coste de computación. Actualmente solo sirve para cifrar la clave de encriptación final generada con el Cipher Suite por tal de asegurar la seguridad de la conexión ya que si mandásemos dicha clave sin cifrado alguno, podría ser interceptada y usada por un atacante para ver el contenido de los paquetes.

Algoritmos (algunos) disponibles para la generación de claves publicas y privadas

  • Diffie-Hellman
  • RSA
  • DSA
  • ElGamal
  • Criptografía de curva elíptica
  • Criptosistema de Merkle-Hellman
  • Goldwasser-Micali
  • Goldwasser-Micali-Rivest
  • Cifrado extremo a Extremo

Por ultimo tenemos el Cipher Suite que es el algoritmo capaz de encriptar y desencriptar la información. En el caso de nuestra imagen es el AES_128_GCM que traducido es el algoritmo AES de 128 bits con un modo de operación de la clave simetrica llamado Galois Counter Mode. El algoritmo utilizado es el que se ha negociado (siempre el mejor) con el servidor de tal manera que de esta lista, se escogerá el que nuestro navegador considere el mejor.

  • DES
  • 3DES
  • RC5
  • AES
  • Blowfish
  • IDEA.

Podria darse el caso que el Cipher Suite se especificase toda la conexion, por ejemplo TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS Protocolo usado
  • ECDHE_RSA algoritmo de intercambio de las claves publica y privada durante el handshake.
  • AES_128_GCM cifrado simetrico que se utilizara durante el resto de la conexión
  • SHA256 sirve para crear un hash para validar los datos recibidos (integridad de los datos)