Nel tentativo di ridurre gli attacchi man in the middle, quando sarà (o è stato) una pratica accettata dal settore di rifiutare le connessioni SSL 2.0 sul lato client e server?
È sufficiente configurare questo proxy su un proxy per proteggere un insieme di host dietro di esso? (Aggiornamento: Leggi qui la risposta a questa domanda o scorri verso il basso)
Riguardo l'ultima parte della tua domanda: no, un proxy non può normalmente proteggere un gruppo di stazioni client dai problemi SSLv2. In SSL / TLS , le cose vanno principalmente in questo modo:
ClientHello in cui viene indicato il numero massimo di versione del protocollo che accetta (TLS 1.0 viene quindi annunciato come "SSL 3.1"). ServerHello che specifica la versione del protocollo che verrà effettivamente utilizzata. Finished (uno dal client, uno dal server) che contengono alcuni dati che sono un hash calcolato sui messaggi precedentemente scambiati . Il server (o il client), dopo aver ricevuto il messaggio Finished dal client (risp. Server), ricalcola l'hash previsto; in caso di mancata corrispondenza, chiude la connessione. Ora vediamo cosa succede quando c'è un proxy. Un proxy HTTP dovrebbe gestire richieste e risposte HTTP. SSL non è un protocollo richiesta-risposta; si aspetta e fornisce un tunnel bidirezionale. Quindi qualcosa di speciale è stato progettato in HTTP (specificato in RFC 2817 , sezione 5): il client invia un ordine CONNECT al proxy, istruendolo a inoltrare tutti i byte di dati successivi in entrambe le direzioni.
Pertanto, anche in presenza di un proxy HTTP, la crittografia si verifica ancora tra il client e il server. Il proxy vedrà i messaggi di handshake, ma (questo è il punto importante) non può modificarli, perché ciò significherebbe compromettere i calcoli hash per i messaggi Finished : il client e il server non avrebbero visto gli stessi esatti messaggi di handshake, calcolerebbero hash distinti e ci sarebbero state mancate corrispondenze con i messaggi Finished . In particolare, se il client invia un ClientHello che afferma di supportare SSLv2 (cioè un ClientHello che utilizza il formato SSLv2, mentre scrive ancora in "Supporto fino a 3.1"), il proxy non può cambiarlo.
Nota: nel protocollo SSLv2, l'handshake non ha messaggi Finished . Quindi un utente malintenzionato in grado di intercettare entrambe le direzioni (il proxy è in una posizione ideale per questo) potrebbe dirottare un ClientHello nel formato SSLv2 e modificare la "versione massima supportata" da 3.1 a 2.0. Questo può imporre client e server compatibili con SSLv2 per utilizzare SSLv2, anche se entrambi supportano SSLv3 +. Questo è chiamato "attacco di versione rollback". La specifica TLS 1.0 include una soluzione alternativa che blocca tale attacco (sezione E.2).
In alto ho scritto "normalmente". Esiste una cosa strana che il proxy può fare in alcuni casi. In particolare, il proxy "attacca" la connessione, in un vero man-in-the-middle-way . Ciò richiede che il proxy produca sul posto un falso certificato del server, con una CA ad hoc incorporata; il certificato radice corrispondente deve essere stato installato nel client (ad esempio, non preoccuparti, il tuo proxy ISP non può forzarlo su di te).
Esistono tali proxy di dirottamento; questo inganno viene utilizzato per applicare tecniche di filtraggio aggressive sul contenuto scambiato (è anche un po 'disapprovato, perché si basa su un po' di rottura delle basi della sicurezza SSL). Un proxy hijacking teoricamente esegue un SSLv2 con il client e un SSLv3 + con il server previsto, in effetti "protegge diversi client da SSLv2".
In pratica , il software che conosce SSLv2 ma non SSLv3 è piuttosto raro; nel caso dei browser Web, questo ci riporta alla metà degli anni Novanta. Quindi puoi, in generale, vietare totalmente SSLv2 da tutte le tue configurazioni, e le cose funzioneranno bene.
Per quanto riguarda le pratiche accettate dall'industria:
(dal link )
"SSLv2 has been deprecated and is no longer recommended. Note that neither SSLv2 nor SSLv3 meet the U.S. FIPS 140-2 standard, which governs cryptographic modules for use in federal information systems. Only the newer TLS (Transport Layer Security) protocol meets FIPS 140-2 requirements. In addition, the presence of an SSLv2-only service on a host is deemed a failure by the PCI (Payment Card Industry) Data Security Standard. Note that this vulnerability will be reported when the remote server supports SSLv2 regardless of whether TLS or SSLv3 are also supported."
La retrocompatibilità è una di quelle cose che dovremmo chiedere di andare via. Ogni CISO / CSO di ogni azienda dovrebbe dire ai produttori di prodotti di morire nel fuoco se supportano SSL 2.0, WEP, ecc.
Penso che spetti a noi (la professione di sicurezza) far sì che ciò accada, ad esempio:
Se eseguiamo un audit IT, dobbiamo assicurarci che il comitato di audit veda un ROSSO quando esiste SSL v2
Se lavoriamo con gli sviluppatori web, dobbiamo rendere chiaro che il loro software non sarà accettato a meno che non utilizzi almeno SSL v3, o idealmente TLS
Se gestiamo progetti, dobbiamo fallire qualsiasi fornitore che cerchi di venderci software che utilizza SSL v2
NOI siamo quelli che hanno bisogno di tecnici degli acquirenti / sviluppatori / responsabili di progetto / amministratori delegati che li danneggeranno se SSL v2 è usato - ma dobbiamo farlo nel linguaggio commerciale. Il PCI DSS è molto utile in questo senso in quanto può costringere i fornitori di servizi di carte a migliorare e, si spera, li usiamo come esempio per persuadere altre organizzazioni.
Leggi altre domande sui tag cryptography proxy network tls attack-prevention