È sicuro abilitare il supporto Clientvello SSLv2?

Question

È sicuro abilitare il supporto Clientvello SSLv2?

#1 da (3 voti)
#2 da (3 voti)

4

In seguito all'attacco di POODLE, molti siti Web hanno abbandonato il supporto per SSLv3. Ma alcuni client ancora in uso relativamente comune a partire da maggio 2015 avviano ancora l'handshake con un messaggio Clientvello SSLv2. Ad esempio, openssl 0.9.8 fornito con Mac OS X 10.10 e Java 6, anch'esso ancora in uso comune almeno su Mac OS X.

Oracle raccomanda che i server che utilizzano il JSSE terminino SSL mantiene abilitato lo pseudo-protocollo SSLv2Hello, che a sua volta consente un handshake SSLv2 ClientHello, per compatibilità con questi client. (Vedi le righe della tabella "Sviluppatori che utilizzano API JSSE - Server").

Sebbene i client che utilizzano SSLv2 ClientHello siano vulnerabili agli attacchi di downgrade del protocollo, ciò vale anche per i client che utilizzano versioni successive di handshake, a meno che sia il client che il server supportino TLS_FALLBACK_SCSV. E fintanto che il server ha disabilitato SSLv2 e SSLv3, l'handshake non può completare con un protocollo inferiore a TLSv1. E sospetto che i client che supportano TLSv1.1 o versioni successive non utilizzino comunque SSLv2 ClientHello, quindi mi sembra una configurazione ragionevole.

Ci sono dei vettori di attacco conosciuti che mi sono sfuggiti, il che renderebbe sconsigliabile mantenere abilitato il supporto SSLv2 ClientHello?

java tls

posta jbyler 23.05.2015 - 01:56

fonte

2 risposte

3

Nota: Java / JSSE non implementa SSLv2 reale (solo Hello), quindi non è necessario disabilitarlo. Come dice l'articolo collegato, gli aggiornamenti recenti disabilitano SSLv3 per impostazione predefinita, ma puoi riattivarlo; prova a non.

Attacchi: non penso ci siano attacchi diretti da v2Hello, ma potrebbero esserci limitazioni funzionali. Prevalentemente impedisce l'uso di estensioni, alcune delle quali sono ora importanti o vitali: SNI potrebbe essere necessario per host virtuali o simili; Le ECcurve e probabilmente i sigalg possono essere necessari per negoziare correttamente la crittografia preferita o persino utilizzabile. (Renego_info è necessario per ogni handshake successivo , ma dovrebbe essere possibile modificare il formato, anche se non ho controllato, sull'handshake iniziale emptyRI-SCSV è sufficiente e sembra principalmente preferito comunque.)

Clienti: OpenSSL 0.9.8 riga di comando s_client imposta di default su v2hello, ma -no_ssl2 o più% specifico -ssl3 o -tls1 lo corregge; un'app che utilizza qualsiasi OpenSSL deve selezionare un protocollo specifico o utilizzare il metodo "v23" (ora chiamato in causa) per supportare un intervallo che potrebbe essere esplicito, tranne che in 1.0.0 + "v23" deseleziona automaticamente il protocollo SSLv2 e formato v2hello se la lista numerica non include alcuna cifratura SSLv2 e la lista numerica predefinita no. Il client Java6 v2hello può essere disabilitato nell'app, se è hardcoded per farlo, configurabile per farlo, oppure hai sorgente e puoi cambiarlo - o almeno la relativa parte (s) di esso, dato che molte applicazioni Java sono principalmente librerie e colla.

risposta data 23.05.2015 - 23:28

fonte

Leggi altre domande sui tag java tls

Login bancario in un paese straniero Perché una scansione nmap dà risultati diversi a seconda che venga eseguita all'interno o all'esterno di una LAN

score 3 · Accepted Answer

Alla luce della recente vulnerabilità DROWN , ora è fondamentale che disabiliti i protocolli SSLv2 su qualsiasi server che potrebbe fornire l'attaccante la possibilità di fare strette di mano. Ora è considerato non solo insicuro, ma estremamente critico poiché può compromettere altri server che utilizzano lo stesso certificato. Maggiori informazioni qui e qui .

SSLv2Hello è sicuro contro di esso e può essere utilizzato poiché in realtà non esegue l'handshake completo, ma piuttosto negozia il protocollo su cui effettuare l'handshake.