Presa chiusa a seconda dei dati. Sono di fronte a un firewall attivo? (DPI - Deep Packet Inspection)

Question

Presa chiusa a seconda dei dati. Sono di fronte a un firewall attivo? (DPI - Deep Packet Inspection)

#1 da (3 voti)

2

Seguendo la mia risoluzione dei problemi relativi alla connessione TLS (Vedi: Test di TLS con openssl ), sembra che potrebbe esserci un firewall attivo sul posto.

La connessione su quella porta funziona con nc su entrambi i lati ( nc -l -p 8883 sul server, nc server.com 8883 sul client)
Funziona anche se invio manualmente il preambolo binario per fare una connessione TLS, ma non conteggio dell'ultimo byte (di nuovo, catturato con nc -l -p 8883 | xxd ). Penso di vedere un ritardo ...
Solo in caso ho verificato anche se la connessione è stata forzata a 289 byte, quindi ho inviato un sacco di testo casuale e ha funzionato bene.
L'invio del preambolo TLS completo genera nulla ricevuto sul server e la connessione chiusa . Ho provato ad aggiungere un po 'di ritardo prima dell'ultimo byte, passa e la connessione rimane aperta!

Che diamine è questo e come posso esprimere la mia richiesta all'IT aziendale per consentirlo? (abbiamo un APN speciale configurato con AT & T e penso che sia dov'è)

Dettagli sulla risoluzione dei problemi:

Ho usato nc -l -p 8883 per acquisire il preambolo TLS da un tentativo di connessione riuscito al server da altrove (289 byte)

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

Quindi ecco il comando client per riprodurlo:

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

< 0.3s, fallisce
= 0.3s non riesce a intermittenza
> 0,3, ha esito positivo

openssl firewalls tls dpi

posta Michael 26.04.2017 - 02:37

fonte

1 risposta

Leggi altre domande sui tag openssl firewalls tls dpi

Dispositivo Rogue trovato in rete È possibile decifrare 802.11 per l'impresa WPA?

score 3 · Answer 1

Girato al buio, ma forse questo è un firewall o un altro middlebox che non può gestire ClientHello con campo lunghezza > = 256 (e quindi utilizzando entrambi i byte della codifica).

Quando OpenSSL 1.0.1 implementò per la prima volta TLS1.2 (e 1.1) nel 2012, risultando in ClientHello contenente più cifhersuites e estensioni aggiuntive e quindi, per impostazione predefinita, superando 256 per la prima volta, ci fu una sfilza di rapporti di rottura sui server che non era stato codificato correttamente per gestire questo; Non ricordo problemi simili con i firewall, ma non è impossibile.

Per provare, prova s_client con -no_tls1_2 (o più semplicemente con -tls1 o -tls1_1 come vuoi) per vedere cosa succede. Puoi aggiungere -debug a s_client per vedere esattamente cosa viene inviato e ricevuto, e in particolare i due byte che iniziano con l'offset 3 in ogni record sono la lunghezza (big-endian) del contenuto di quel record: nel tuo esempio questo è 011c e l'intestazione del record di 5 byte più 0x011c byte di contenuto corrisponde al totale 0x0121 byte.