In che modo DPI sostanzialmente identifica il traffico di dati SSL? Solo per il numero "443" nella sezione della porta o il traffico SSL ha altre proprietà particolari diverse da "443"?
Grazie in anticipo,
SSL / TLS ha un formato on-the-wire molto specifico per i dati: i dati vengono inviati come record . Inoltre, all'inizio di ogni connessione:
ClientHello . Quindi il primo byte dal client sarà 0x16. Segue la versione del protocollo, che sarà di due byte: 0x03, quindi un byte del valore (normalmente) 0x00 (per SSL 3.0) a 0x03 (per TLS 1.2). Quindi la lunghezza del record come due byte. All'interno del carico utile del record viene trovata l'intestazione del messaggio di handshake: un byte di valore 0x01 (tipo per ClientHello ) seguito da una lunghezza di tre ottetti.
A un certo punto, avevo usato un multiplexer per SSL e RDP sulla stessa porta: da quando ha inizio la connessione RDP con un byte di valore 0x03 dal client, mentre il primo byte di SSL è 0x16, quindi potrei scrivere un semplice programma che ha inoltrato i dati al server Web o al server RDP, a seconda del primo byte.
Non tutti i sistemi DPI sono sofisticati e alcuni possono essere ingannati applicando varianti del protocollo. Ad esempio, il client può dividere il messaggio ClientHello in più record e possibilmente iniziare con un lungo flusso di record vuoti. Alcune implementazioni del server in realtà tollerano una sequenza iniziale di un migliaio di messaggi di avviso (di tipo "warning") che possono eludere il controllo del sistema DPI in diversi modi:
ClientHello sia contenuto in un singolo record, senza frammentazione, e quindi non riconosce l'handshake SSL. ClientHello nel primo pacchetto della connessione TCP, e tutti i record o record di allarme extra vuoti potrebbero spingere il ClientHello arbitrariamente nella connessione TCP. Il trucco qui è trovare le varianti che sono accettate dalle implementazioni del server SSL (che hanno anch'esse alcune limitazioni arbitrarie più o meno) ma non sono coperte da qualunque sistema DPI tu stia cercando di nascondere.
(Se non sei sicuro, prova ad implementare una libreria SSL personalizzata - per l'apprendimento, non per l'uso di produzione, naturalmente. Questo ti insegnerà molte cose sui dettagli del protocollo.)
Per stabilire TLS / SSL, le parti devono prima handshake (che viene condotta in chiaro, al livello 5 del modello OSI). Un intercettatore può facilmente riconoscere questo processo e registra che la connessione utilizza TLS / SSL.
Da allora in poi, la comunicazione tra le parti è crittografata (al livello 6) e un intercettatore non può intercettare i dati dell'applicazione (al livello 7).
Tuttavia, come hai notato, i livelli più bassi possono ancora essere osservati: in particolare, si può essere in grado di inferire il protocollo dell'applicazione da numero di porta TCP (al livello 4). La porta 443 è riservata da IANA per HTTPS, quindi HTTP sarebbe una buona ipotesi (si potrebbe anche eseguire un attacco attivo e tentare di comunicare con il server per vedere se risponde a una richiesta HTTP su TLS su quella porta).
Inoltre, non dimenticare che l'analisi del traffico può rivelarsi estremamente istruttiva. Con SMTP ci si aspetterebbe una breve stretta di mano bidirezionale seguita da una mole di dati inviati dal cliente, seguita da un breve addio a due vie; questo sarebbe in contrasto con HTTP dove ci si aspetterebbe una breve richiesta inviata dal client seguita da una risposta più ampia dal server. Infatti, utilizzando solo analisi del traffico, i ricercatori sono stati in grado di di indovinare con precisione esattamente quali risorse HTTP hanno richiesto dai clienti su TLS.
Leggi altre domande sui tag tls