Se mi sono protetto da POODLE sono protetto anche contro DROWN

Tieni presente che una recente versione di OpenSSL aveva un bug ( CVE-2015- 3197 ) che consentiva a un client di negoziare suite di crittografia disabilitate (come le crittografie EXPORT di SSLv2, per DROWN) anche se erano disabilitate in OpenSSL in fase di runtime. Assicurati di essere aggiornato (sempre una buona idea comunque, specialmente con cose come OpenSSL), e disabilita tutte le versioni di SSL. Non dimenticare di riavviare i processi del server dopo aver aggiornato la libreria, in modo che raccolga la nuova versione della libreria OpenSSL.

Inoltre, tieni presente che DROWN può essere sfruttato su server che ospitano diversi protocolli (ad esempio, utilizzando un server di posta elettronica per attaccare una connessione HTTPS) se l'altro server supporta SSL2 e sta utilizzando la stessa chiave pubblica del tuo server web. Dal momento che riutilizzare le chiavi pubbliche è ragionevolmente comune, e poiché le connessioni sicure ai server di posta elettronica (e simili) di solito non sono soggette a tanto scrupolo quanto la sicurezza delle connessioni dei server Web, potresti comunque essere vulnerabile a DROWN anche se il tuo web server non consente SSLv2.

POODLE è un abuso di una falla in SSL 3.0. Sei tecnicamente protetto da POODLE se hai disattivato il supporto per SSL 3.0.

DROWN sfrutta un difetto in SSL 2.0. Potresti essere tecnicamente protetto da POODLE, nel senso spiegato sopra, e comunque essere vulnerabile a DROWN.

Ovviamente, SSL 2.0 ha altri difetti ed era già deprecato / proibito; è stato così per molto tempo. Il consiglio per POODLE è stato spesso definito come "disattivare tutto ciò che è più vecchio di TLS 1.0" e questo include SSL 2.0, ma, onestamente, SSL 2.0 dovrebbe essere già stato disattivato, ucciso e il suo cadavere scaricato in mare, molto prima di POODLE. Se dovessi aspettare che POODLE disabiliti SSL 2.0, allora eri già molto sciatto. Non esiste un limite superiore alla sciatteria, quindi sei incoraggiato a verificare se il tuo server accetta ancora SSL 2.0. Per ogni evenienza.

Dipende.

Sei vulnerabile a DROWN se QUALSIASI server ha la stessa chiave RSA della tua e sta eseguendo SSLV2 e consente la "crittografia di esportazione" a bassa sicurezza. Esempi di questo potrebbero essere un certificato con più nomi alternativi o un certificato jolly.

Ad esempio:

Hai disattivato SSLV2 e SSLV3 sul tuo server web. Un altro amministratore della tua organizzazione, Bob condivide lo stesso certificato SSL con te, entrambi con un nome alternativo e condividono quindi la stessa chiave RSA. Il tuo server è www.mydomain.com con https e il server di Bob è email.mydomain.com, con SSL su SMTP.

Bob è un po 'più sciatto su SSL e non ha disabilitato SSLV2 sul suo server. Poiché entrambi avete la stessa chiave RSA, un utente malintenzionato può utilizzare il server configurato male di Bob per compromettere la sicurezza SSL del server configurato correttamente.

Al momento, Labs SSL ha un test per l'attacco DROWN al loro server di gestione temporanea e hanno un eccellente scrivi sulla vulnerabilità .

Alcuni dei punti salienti che potrebbero essere già stati toccati in altre risposte:

...we have known SSL v2 to be insecure for a very long time—over 20 years.

...DROWN actually makes things worse, because it abuses SSL v2 to attack all other protocols

...the security of a server can’t be determined only by looking at its configuration. For DROWN, we have to look for the presence of the server’s RSA keys and/or certificate hostnames elsewhere.