Handshake TLS

Una conexión segura se establece a través de un proxy mediante el handshake TLS, donde el cliente y el servidor final (ya sea el origen o el propio proxy, dependiendo de la configuración) autentican identidades y negocian parámetros criptográficos para crear un canal de comunicación cifrado. Este proceso garantiza la confidencialidad, integridad y autenticidad de los datos para las aplicaciones que se comunican a través de redes.

Comprensión del Handshake TLS

El protocolo Transport Layer Security (TLS) es fundamental para asegurar las comunicaciones por internet. Opera por encima de la capa de transporte (TCP) y proporciona cifrado y autenticación de extremo a extremo. El handshake TLS es la fase de negociación inicial donde el cliente y el servidor acuerdan los parámetros criptográficos y establecen una sesión segura antes de que se intercambien los datos de la aplicación.

Los objetivos principales del handshake TLS son:
* Autenticación: Verificar la identidad del servidor (y opcionalmente del cliente) utilizando certificados digitales.
* Intercambio de Claves: Acordar de forma segura una clave secreta compartida para el cifrado simétrico.
* Negociación de Suite de Cifrado: Seleccionar los algoritmos para cifrado, hashing e intercambio de claves.

Pasos del Handshake TLS Directo

En una conexión directa sin proxy, el handshake TLS procede de la siguiente manera:

1. Client Hello: El cliente inicia el handshake enviando un mensaje Client Hello. Este mensaje incluye:
   • Versiones de TLS compatibles.
   • Una lista de suites de cifrado compatibles.
   • Una cadena de bytes aleatoria (Client Random).
   • Métodos de compresión compatibles.
   • Server Name Indication (SNI) para alojamiento virtual.
2. Server Hello: El servidor responde con un mensaje Server Hello, seleccionando:
   • La versión de TLS a utilizar.
   • Una suite de cifrado elegida de la lista del cliente.
   • Una cadena de bytes aleatoria (Server Random).
3. Certificate: El servidor envía su certificado digital, que contiene su clave pública y está firmado por una Autoridad de Certificación (CA). El cliente verifica este certificado.
4. Server Key Exchange (Opcional): Si la suite de cifrado elegida lo requiere (por ejemplo, para Diffie-Hellman efímero), el servidor envía parámetros para el intercambio de claves.
5. Server Hello Done: El servidor indica que ha completado su parte del handshake inicial.
6. Client Key Exchange: El cliente genera un secreto pre-maestro, lo cifra con la clave pública del servidor (de su certificado) y lo envía al servidor.
7. Change Cipher Spec (Cliente): El cliente envía un mensaje Change Cipher Spec, indicando que todos los mensajes subsiguientes serán cifrados utilizando las claves y la suite de cifrado negociadas.
8. Encrypted Handshake Message (Cliente): El cliente envía un mensaje Finished, cifrado con la clave simétrica recién establecida, para verificar la integridad del handshake.
9. Change Cipher Spec (Servidor): El servidor envía su propio mensaje Change Cipher Spec.
10. Encrypted Handshake Message (Servidor): El servidor envía su mensaje Finished, también cifrado.
11. Application Data: Ambas partes pueden ahora intercambiar datos de aplicación cifrados.

Tipos de Proxy e Interacción del Handshake TLS

Los proxies modifican cómo se inicia y procesa el handshake TLS según su modo de operación.

Proxy de Reenvío (No Interceptor)

Un proxy de reenvío actúa como intermediario para los clientes que buscan acceder a recursos externos. Para el tráfico HTTPS, un proxy de reenvío no interceptor típicamente opera como un túnel TCP. El cliente se configura explícitamente para usar el proxy.

Mecanismo:
El cliente envía una solicitud HTTP CONNECT al proxy para establecer un túnel TCP al servidor de origen. Una vez que se establece el túnel, el cliente y el servidor de origen realizan el handshake TLS directamente a través de este túnel. El proxy reenvía los bytes cifrados sin descifrarlos.

Flujo del Handshake TLS:
1. Cliente a Proxy (TCP): El cliente establece una conexión TCP con el proxy.
2. Solicitud CONNECT del Cliente: El cliente envía una solicitud HTTP CONNECT al proxy, especificando el nombre de host y el puerto del servidor de origen (ej., CONNECT example.com:443 HTTP/1.1).
3. Proxy a Origen (TCP): El proxy establece una conexión TCP con el servidor de origen especificado.
4. 200 OK del Proxy: Si la conexión con el servidor de origen es exitosa, el proxy responde al cliente con HTTP/1.1 200 Connection established.
5. Cliente a Origen (TLS vía Túnel): El cliente, al recibir el 200 OK, inicia el handshake TLS estándar directamente con el servidor de origen a través del túnel TCP establecido.
6. Reenvío del Proxy: El proxy reenvía transparentemente todos los bytes cifrados subsiguientes entre el cliente y el servidor de origen. No participa en el handshake TLS, ni descifra el tráfico.

Ejemplo de Código: Solicitud CONNECT del Cliente

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive

Respuesta del Proxy

HTTP/1.1 200 Connection established

Proxy Inverso (Terminación TLS)

Un proxy inverso se sitúa delante de uno o más servidores de origen e intercepta las solicitudes del cliente destinadas a esos servidores. Para el tráfico HTTPS, un proxy inverso a menudo realiza la terminación TLS.

Mecanismo:
El proxy inverso recibe la solicitud HTTPS del cliente, termina la conexión TLS, descifra el tráfico y luego establece una nueva conexión (que puede o no estar cifrada con TLS) con el servidor de origen backend.

Flujo del Handshake TLS:
1. Cliente a Proxy Inverso (Handshake TLS 1):
* El cliente realiza un handshake TLS estándar directamente con el proxy inverso.
* El proxy inverso presenta su propio certificado digital al cliente.
* Se establece un canal seguro y cifrado entre el cliente y el proxy inverso.
2. Descifrado del Proxy Inverso: El proxy inverso descifra la solicitud del cliente.
3. Proxy Inverso a Origen (Handshake TLS 2 o HTTP):
* El proxy inverso inicia una nueva conexión con el servidor de origen backend apropiado.
* Esta conexión puede ser HTTP simple (común en redes internas de confianza) o otra conexión cifrada con TLS (para cifrado de extremo a extremo).
* Si se utiliza TLS, el proxy inverso actúa como cliente y realiza un segundo handshake TLS con el servidor de origen, que presenta su propio certificado.
4. Procesamiento del Origen: El servidor de origen procesa la solicitud y envía la respuesta de vuelta al proxy inverso.
5. Cifrado del Proxy Inverso: Si la conexión con el cliente fue TLS, el proxy inverso vuelve a cifrar la respuesta utilizando las claves de sesión TLS orientadas al cliente.
6. Proxy Inverso a Cliente: La respuesta cifrada se envía de vuelta al cliente.

Proxy Transparente (Intercepción TLS MITM)

Un proxy transparente intercepta el tráfico sin que el cliente esté configurado explícitamente para usarlo. Para HTTPS, esto típicamente implica un enfoque de Man-in-the-Middle (MITM).

Mecanismo:
Cuando un cliente intenta conectarse a un sitio HTTPS, el proxy transparente intercepta la conexión. Genera un certificado falso para el dominio solicitado, firmado por su propia CA raíz. El cliente realiza un handshake TLS con el proxy, que luego realiza otro handshake TLS con el servidor de origen. Esto permite al proxy descifrar, inspeccionar y potencialmente modificar el tráfico. Para que esto funcione sin errores de certificado, el certificado de la CA raíz del proxy debe ser de confianza para el cliente. Esto es común en entornos empresariales para la monitorización de seguridad.

Comparación de Tipos de Proxy e Interacción TLS

Consideraciones de Seguridad

Al establecer conexiones seguras a través de un proxy, surgen varias implicaciones de seguridad:

• Confianza en el Proxy:
  • Proxy de Reenvío: Dado que el proxy solo tuneliza datos cifrados, los requisitos de confianza son mínimos en cuanto a la confidencialidad de los datos. Sin embargo, el proxy podría potencialmente registrar metadatos de conexión (IPs, dominios).
  • Proxy Inverso / Proxy Transparente (MITM): Estos proxies descifran el tráfico. La confianza en el operador del proxy se vuelve primordial, ya que tienen acceso a datos sensibles descifrados. Para los proxies transparentes MITM, el cliente debe confiar explícitamente en la CA raíz del proxy, típicamente instalándola en el almacén de confianza del sistema.
• Certificate Pinning: Las aplicaciones que utilizan certificate pinning podrían fallar al conectarse a través de un proxy inverso o un proxy transparente MITM, ya que el proxy presenta un certificado diferente al certificado esperado del servidor de origen. Esta es una característica de seguridad diseñada para prevenir ataques MITM.
• Aplicación de Versión TLS y Suite de Cifrado: Los proxies pueden configurarse para aplicar versiones TLS y suites de cifrado específicas, mejorando la seguridad al no permitir protocolos criptográficos obsoletos o débiles, incluso si el cliente o el servidor de origen los soportan.
• Registro y Auditoría: Los proxies, especialmente los de tipo inverso y transparente, pueden proporcionar amplias capacidades de registro para el tráfico descifrado, lo que ayuda en las auditorías de seguridad y la respuesta a incidentes.
• Sobrecarga de Rendimiento: La terminación TLS en un proxy introduce una sobrecarga computacional para el cifrado y descifrado, lo que debe considerarse en entornos de alto tráfico. La aceleración de hardware (ej., descarga SSL) se utiliza comúnmente para mitigar esto.