Il modo migliore per cercare ed eliminare versioni precedenti di SSL / TLS in un ambiente di produzione

@atdre punta a uno strumento che dovrebbe consentire di rilevare se un determinato server supporta TLS 1.2, ma questa è solo una parte della storia. In SSL / TLS, i passaggi iniziali di una connessione sono l' handshake in cui sono concordati un numero di parametri tra client e server, inclusa la versione del protocollo che verrà utilizzata. Il client annuncia la versione di protocollo più elevata supportata, quindi il server sceglie la versione che verrà utilizzata (normalmente, la versione più alta che il server conosce, ma non superiore alla versione massima annunciata dal client).

Pertanto, anche se tutti i server sono pronti per utilizzare TLS 1.2, ciò non implica necessariamente che verrà utilizzato solo TLS 1.2; dipende da ciò che i server accettano, oltre a TLS 1.2, e da ciò che i clienti supportano. Per un dato server, hai fondamentalmente due metodi per accertarti che TLS 1.2 sarà usato:

1. Assicurati che il server supporti solo TLS 1.2: se un client annuncia "TLS 1.1" come versione più alta, il server dovrebbe rifiutarlo. Se un server accetta solo TLS 1.2, verrà utilizzato solo TLS 1.2 quando si parla con questo server.

2. Verificare che tutti i client che parlano al server annunciano TLS 1.2 come versione più alta e il server accetta. Ciò implica fondamentalmente l'esecuzione di uno strumento di monitoraggio della rete (ad esempio Wireshark ) per osservare i messaggi ClientHello effettivamente inviati dai client e ServerHello messaggi inviati in risposta.

Ulteriori complicazioni derivano dal comportamento di "auto downgrade" di alcuni client (tipicamente i browser Web). Il client può provare a connettersi, in primo luogo, inviando un ClientHello che dice "I support up to TLS 1.2". Se ciò non riesce, tuttavia, il client potrebbe pensare che il server potrebbe essere allergico a TLS 1.2 - è noto che ci sono ancora alcuni server Web distribuiti che non seguono correttamente le specifiche e semplicemente rilasciano le connessioni quando vedono "TLS 1.2 "perché non lo capiscono. Per supportare questi server mal implementati, alcuni client SSL / TLS, in seguito a un errore di handshake, tenteranno di nuovo, questa volta con un ClientHello che annuncia "I support up to TLS 1.0".

Sfortunatamente (per la situazione attuale), ciò significa che anche se un client e un server sembrano utilizzare TLS 1.2 in condizioni normali, un utente malintenzionato attivo può interrompere bruscamente le connessioni che iniziano con un handshake TLS 1.2 (l'autore dell'attacco attivo inserisce RST spuri pacchetti per uccidere la connessione TCP sottostante). In tale situazione, l'autore dell'attacco può attivare il meccanismo di downgrade automatico e forzare il client e il server a utilizzare una versione inferiore.

Quindi, se vuoi veramente assicurarti che venga utilizzato solo TLS 1.2, anche in presenza di un attaccante astuto, allora dovrebbe applicarsi solo il primo metodo. In altre parole, utilizzando sslyze o qualsiasi altro strumento simile, è necessario assicurarsi che quando un client richiede TLS 1.2, ottiene TLS 1.2, E inoltre che se un client richiede TLS 1.1, il server lo rifiuta.

La valutazione attiva di tutti gli indirizzi IP e nomi host conosciuti è il metodo migliore per controllare un'infrastruttura fino alla piena conformità.

sslyze --sslv2 --sslv3 --tlsv1 --tlsv1_1 --targets_in=target-list.txt --xml_out=sslyze.xml

Puoi ottenere sslyze qui - link

Potresti anche aver bisogno di uno sviluppatore che capisca l'analisi XML per ordinare meglio i risultati.

Che cosa intendi con "c'è un modo per automatizzare ... invece di esaminare una lista"? L'automazione non richiederebbe un elenco?

Posso pensare a due potenziali modi per eseguire un test senza connettersi a ciascun server. Uno sarebbe utilizzare una configurazione gold standard e verificarla con uno strumento come Lynis. È possibile visualizzare uno script che controlla i server Web per le loro configurazioni (incluso un controllo SSL / TLS dettagliato per nginx) qui - link

Il modo finale per rilevare i servizi nel proprio ambiente che eseguono versioni SSL / TLS non conformi sarebbe quello di utilizzare un'infrastruttura di acquisizione dei pacchetti. Esistono numerosi modi per configurare il proprio ambiente per le valutazioni di acquisizione della rete, e qui non ne parlerò. Tuttavia, ho visto alcuni strumenti che controllano le intestazioni del server (che possono fornire una libreria SSL / TLS o la versione del modulo) e / o i protocolli stessi. Nella prima categoria: snort, prads e tshark possono essere ottimi modi per interagire con le interfacce di acquisizione live e / o i dati memorizzati su pcap. In quest'ultima categoria: ssldump e pyshark possono essere creati per fornire informazioni dettagliate sul protocollo. Entrambe queste tecniche, tuttavia, saranno in grado di mostrare solo i servizi SSL / TLS che sono in uso; non mostreranno servizi dormienti SSL / TLS che non sono in uso o che non sono comunemente in uso. Un'altra enorme vittoria qui è tls-fingerprinting (ad es. Fingerprintls) e associata snort rules .