¿Cómo identifica DPI básicamente el tráfico de datos SSL? ¿Solo por el número "443" en la sección del puerto o el tráfico SSL tiene otras propiedades particulares distintas de "443"?
Gracias de antemano,
SSL / TLS tiene un formato muy específico en línea para los datos: los datos se envían como registros . Además, al comienzo de cada conexión:
ClientHello . Entonces, el primer byte del cliente será 0x16. Luego sigue la versión del protocolo, que será de dos bytes: 0x03, luego un byte de (normalmente) valor 0x00 (para SSL 3.0) a 0x03 (para TLS 1.2). Entonces la longitud de registro como dos bytes. Dentro de la carga útil de registro se encuentra el encabezado del mensaje de intercambio: un byte de valor 0x01 (tipo para un ClientHello ) seguido de una longitud de tres octetos.
En algún momento, había usado un multiplexor para SSL y RDP en el mismo puerto: desde que comenzó la conexión RDP con un byte de valor 0x03 del cliente, mientras que el primer byte de SSL es 0x16, por lo que podría escribir un programa simple que reenvía los datos al servidor web o al servidor RDP, dependiendo de ese primer byte.
No todos los sistemas DPI son sofisticados, y algunos pueden ser engañados aplicando variantes del protocolo. Por ejemplo, el cliente puede dividir el mensaje ClientHello en varios registros, y posiblemente comenzar con una larga secuencia de registros vacíos. Algunas implementaciones de servidor realmente tolerarán una secuencia inicial de mil mensajes de alerta (de tipo "advertencia") que pueden evadir el escrutinio del sistema de DPI de varias maneras:
ClientHello esté contenido dentro de un solo registro, sin fragmentación, y por lo tanto no reconozca el protocolo de enlace SSL. ClientHello dentro del primer paquete de la conexión TCP, y todos los registros vacíos adicionales o el registro de alerta pueden empujar arbitrariamente al ClientHello a la conexión TCP. El truco aquí es encontrar variantes que sean aceptadas por las implementaciones de servidor SSL (que tienen algunas limitaciones arbitrarias más o menos) pero que no están cubiertas por el sistema de DPI que intenta ocultar.
(Si no está seguro, intente implementar una biblioteca SSL personalizada, por supuesto, no para uso de producción. Esto le enseñará muchas cosas sobre los detalles del protocolo).
Para establecer TLS / SSL, las partes deben primero handshake (que se lleva a cabo de forma clara, en la capa 5 del modelo OSI). Un intruso puede reconocer fácilmente este proceso y registrar que la conexión está utilizando TLS / SSL.
Posteriormente, la comunicación entre las partes se cifra (en la capa 6) y un intruso no puede interceptar los datos de la aplicación (en la capa 7).
Sin embargo, como ha notado, aún se pueden observar niveles más bajos: en particular, uno puede inferir el protocolo de aplicación de número de puerto TCP (en la capa 4). El puerto 443 está reservado por IANA para HTTPS, por lo que HTTP sería una buena conjetura (incluso se podría realizar un ataque activo e intentar comunicarse con el servidor para ver si responde a una solicitud HTTP sobre TLS en ese puerto). / p>
Además, no olvide que el análisis de tráfico puede resultar extremadamente informativo. Con SMTP, uno esperaría un breve apretón de manos bidireccional seguido de una gran cantidad de datos enviados por el cliente, seguido de una corta despedida bidireccional; esto contrastaría con HTTP, donde uno esperaría que el cliente envíe una breve solicitud seguida por una respuesta más amplia del servidor. De hecho, solo con el análisis del tráfico, los investigadores han podido adivinar con bastante precisión exactamente qué recursos HTTP tienen ha sido solicitado por clientes a través de TLS.
Lea otras preguntas en las etiquetas tls