Identifica il traffico SSL HTTPS vs Application

Come indica @aus, puoi provare a osservare le caratteristiche esatte di ClientHello e altre funzionalità SSL (ad esempio come i messaggi sono suddivisi su record) per ottenere indicazioni sul fatto che il client sia un vero browser Web o no . Tuttavia, questo non è robusto:

• Diversi browser agiscono in modo diverso in questa materia. Potresti essere impegnato in un'incessante ricerca in salita, con valutazione continua di tutte le principali versioni del browser.
• Un aggiornamento del SO / browser può cambiare i suoi schemi di utilizzo (ad esempio alcune suite di crittografia vengono abilitate per impostazione predefinita), pertanto il meccanismo di rilevamento potrebbe essere afflitto da picchi di falsi positivi in alcuni momenti imprevedibili (quando Microsoft / Mozilla / Google decide di eseguire il push qualche aggiornamento tecnico).
• Se gli utenti sono a conoscenza di tali impronte digitali, potrebbero iniziare a utilizzare client che imitano le funzionalità che si sta tentando di rilevare. È possibile l'emulazione "perfetta" delle caratteristiche SSL di un "normale Internet Explorer". Fornire un incentivo (un meccanismo di rilevamento che attiva la ritorsione), e accadrà.

Potresti voler effettuare alcune analisi del traffico in base alla tempistica e alle dimensioni delle richieste; quando un browser si connette a un server, invierà prima una richiesta con un'intestazione la cui dimensione dipende da molte cose, ma non sarà troppo piccola. Nel caso specifico di SSH-in-SSL, c'è un modo subdolo per cui la distinzione è semplice: aggiungi un ritardo .

Specificamente, quando un server Web riceve una connessione, attende: il client deve inviare una richiesta. Dall'esterno, si osserva un handshake SSL, che si conclude con i due messaggi Finished (che vengono visualizzati come "handshake crittografati" dal momento che si sta monitorando dall'esterno), quindi il client invierà un record "dati dell'applicazione" (in SSL, i contenuti dei record sono crittografati, ma il tipo del record non lo è: è handshake , alert , change_cipher_spec , o dati dell'applicazione ). Finché i "dati dell'applicazione" dal client non vengono inviati, il server attenderà.

Con SSH, tuttavia, le cose sono diverse. Non appena viene stabilita la connessione, il client e il server si scambiano il proprio "banner" (che indica la versione del protocollo e così via), in nessun ordine particolare. Pertanto, quando il tuo strumento di monitoraggio vede un nuovo handshake SSL, può ritardare temporaneamente il primo record di dati dell'applicazione dal client (diciamo, 0,5 secondi), per vedere se il server invierà spontaneamente un " dati dell'applicazione "registra da solo senza attendere il record dal client. Se il server lo fa, allora non sta parlando HTTP all'interno del tunnel SSL.

Naturalmente, se inizi a implementare un meccanismo di rilevamento di questo tipo, gli utenti si adatteranno, modificando i loro client e server SSH per fare in modo che i server attenderanno il banner del cliente prima di parlare. Questo è destinato a degenerare nello stesso tipo di guerra sterile tra virus e antivirus. Questo è, a lungo termine, estenuante.

Oltre a SSH, il tuo problema più grande saranno i proxy Web. Vale a dire, l'utente:

• Controlla un proxy Web esterno.
• Esegue su quella macchina esterna un server SSL che inoltra semplicemente i byte di dati al proxy Web.
• Esegue sulla sua macchina locale un processo semplice che ascolta sulla porta locale 3128 e inoltra tutti i dati al server SSL.
• Configura il suo browser per utilizzare "localhost: 3128" come proxy per le richieste Web.

Con questa configurazione, tutta la navigazione Web dell'utente sul server passerà attraverso la connessione SSL, fuori dalla portata dei tuoi sistemi di monitoraggio; e, soprattutto, tutte le richieste saranno richieste HTTP da un normale browser Web, quindi indistinguibili dalle richieste HTTP da un normale browser Web. Questo alla fine sconfigge l'analisi del traffico.

La conclusione è che quello che stai cercando di fare è combattere una guerra che non puoi vincere. Ti suggerisco di iniziare a cercare modelli alternativi. Un modo per guardarlo è il seguente: se permetti BYOD sul tuo posto di lavoro, devi fidarti dipendenti per non abusarne e per applicare buone pratiche di sicurezza su se stessi.

Dopo alcune ricerche aggiuntive, credo di aver trovato la risposta alla mia domanda. La tecnica utilizzata per identificare i client SSL si chiama Fingerprinting client SSL . Osservando i vari componenti del ClientHello durante l'handshake SSL, possiamo fare un'ipotesi plausibile se il client SSL è un browser o qualcos'altro.

Questo post del blog descrive l'idea abbastanza bene:

In my previous article I've described the structure of SSL/TLS ClientHello packet.

Importantly, it contains a list of supported ciphers and extensions.

Unsurprisingly, those lists differ between clients and often it is possible to identify an SSL client by looking at them. In other words - it is possible to distinguish Firefox, Chrome, Opera and IE apart by just looking at the initial HTTPS packet, which is unencrypted.

Pertanto, in circostanze normali, sarebbe possibile distinguere tra HTTPS e SSL dell'applicazione.

L'autore continua a parlare di come usare p0f con la sua patch per l'impronta digitale SSL contro un database di firme predefinite .

Il post e research da Ivan Ristić sono entrambi piuttosto affascinanti.

Tuttavia, c'è un'eccezione. Con una granularità sufficiente nelle impostazioni di un client SSL, si potrebbe facilmente emulare un ClientHello simile che sembra provenire da un determinato browser. Data la sufficiente attenzione ai dettagli, non sono sicuro che ci sarebbe un altro modo per distinguere tra SSL del browser e SSL di un'altra applicazione con un handshake accuratamente predisposto.

Poiché il resto del flusso TCP è crittografato, gli unici altri suggerimenti sarebbero la "chatty-ness" tra server e client e la quantità di dati trasferiti.