Socket cerrado dependiendo de los datos. ¿Estoy frente a un firewall activo? (DPI - Inspección profunda de paquetes)

Question

Socket cerrado dependiendo de los datos. ¿Estoy frente a un firewall activo? (DPI - Inspección profunda de paquetes)

#1 de dave_thompson_085 (3 votos)

2

Siguiendo mi solución de problemas para realizar una conexión TLS (consulte: Probando TLS con openssl ), parece que podría haber un firewall activo en su lugar.

La conexión en ese puerto funciona con nc en ambos lados ( nc -l -p 8883 en el servidor, nc server.com 8883 en el cliente)
Incluso funciona si envío manualmente el preámbulo binario para establecer una conexión TLS, pero omito el último byte (nuevamente, capturado con nc -l -p 8883 | xxd ). Creo que veo un retraso ...
Solo en caso de que también verifiqué si la conexión se está forzando a cerrar a 289 bytes, por lo que envié una gran cantidad de texto al azar y fue bien.
Al enviar los resultados del preámbulo TLS completo a no se recibió nada en el servidor, y se cerró la conexión . Intenté agregar un poco de retraso antes del último byte, pasa y la conexión permanece abierta.

¿Qué diablos es esto y cómo expreso mi solicitud a la empresa de TI para permitirlo? (tenemos un APN especial configurado con AT & T y creo que ahí es donde está)

Detalles de resolución de problemas:

Usé nc -l -p 8883 para capturar el preámbulo TLS de un intento de conexión exitosa al servidor desde otro lugar (289 bytes)

0000000: 1603 0101 1c01 0001 1803 03f4 f363 0180  
0000010: 3ce4 957f ee17 8b7f d8ef 9ce0 e608 1cac  
0000020: d328 798d 8b10 cc7b b521 0....
...
0000120: 01

Entonces aquí está el comando del cliente para reproducirlo:

(head TLS1.hex -n18 | xxd -r; sleep 0.3; echo 0: 01 | xxd -r ) 
                                  | nc server.com 8883 -q 1

< 0.3s, falla
= 0.3s falla intermitentemente
> 0.3s, tiene éxito

firewalls tls openssl dpi

pregunta Michael 26.04.2017 - 02:37

fuente

1 respuesta

Lea otras preguntas en las etiquetas firewalls tls openssl dpi

Después de probar la inyección SQL exitosa, ¿por qué el resultado no se muestra en la página web? dispositivo Rogue encontrado en la red

score 3 · Answer 1

Tomado en la oscuridad, pero quizás es un firewall u otro middlebox que no puede manejar ClientHello con un campo de longitud > = 256 (y por lo tanto usa ambos bytes de la codificación).

Cuando OpenSSL 1.0.1 implementó TLS1.2 (y 1.1) por primera vez en 2012, lo que dio como resultado que ClientHello contenía más conjuntos de cifrado y extensiones adicionales y, por lo tanto, por primera vez superaba los 256, hubo una gran cantidad de informes de roturas en los servidores. eso no había sido codificado correctamente para manejar esto; No recuerdo ningún problema similar con los cortafuegos, pero no es imposible.

Para realizar la prueba, intente s_client con -no_tls1_2 (o más simplemente con -tls1 o -tls1_1 como elija) para ver qué sucede. Puede agregar -debug a s_client para ver exactamente lo que se envía y recibe, y en particular los dos bytes que comienzan en el desplazamiento 3 en cada registro son la longitud (big-endian) del contenido de ese registro: en su ejemplo esto es 011c y el encabezado de registro de 5 bytes más 0x011c bytes de contenido coincide con su total de 0x0121 bytes.