Quali sono i rischi di fornire SSLv2 per la compatibilità dei dispositivi aggiuntivi?

L'area che sembra mancare a tutte le altre risposte è che la sicurezza relativa (o la sua mancanza) dell'utilizzo di SSLv2 in termini pratici dipende dal modello di minaccia dell'ambiente in cui verranno utilizzate.

Quindi tutti sarebbero d'accordo sul fatto che SSLv2 sia un protocollo debole (ulteriori dettagli tecnici dall'inimitabile Mr Leek qui . Fondamentalmente un aggressore con MITM avrà più gioia ad attaccare una connessione fatta con SSLv2 e anche dove utilizza cifrari più deboli un attaccante che può vedere il traffico in una connessione potrebbe essere in grado di decrittografarlo più facilmente.In entrambi i casi è giusto dire che questo non è ancora un attacco di basso livello, gli attacchi MITM su SSL non sono banali da eseguire e decrittografare, anche i cifrari relativamente deboli richiedono un po 'di sforzo, ben all'interno dei livelli di attacco dello stato nazionale ma non in generale nel regno del casual o basso -end attackers

In aggiunta a questo abbiamo DROWN, ma il punto chiave su questo è, si applica solo dove un altro server utilizza la stessa chiave privata di quella che esegue SSLv2.

Quindi, dove ci lascia, torna con il tuo modello di minaccia. Chi sono gli aggressori che potrebbero voler compromettere il tuo sistema?

Se guardiamo i professionisti di fascia alta o lo stato nazionale, è giusto dire che SSLv2 non dovrebbe essere in alcun modo nelle carte, poichè le debolezze che è probabile saranno sfruttate da quegli aggressori

Tuttavia, se le tue preoccupazioni sono più vicine agli aggressori casuali o di basso livello che ottengono facilmente l'accesso ai dati in transito (forse vengono trasmessi su una rete wireless che ha altri utenti), realisticamente non penso che tu sia rischia di essere compromesso tramite un attacco su SSLv2

Probabilmente il più grande rischio commerciale concreto in questi scenari è che, dal punto di vista della conformità, questo non avrà un bell'aspetto, e anche se si ottiene un consulente per la sicurezza, lo segnaleranno come un rischio ...

Al di fuori del tuo problema SSLv2, da una prospettiva di sicurezza del mondo reale, sarei probabilmente molto più preoccupato delle probabili vulnerabilità nel software operativo su questi dispositivi, dato che sembra che tu non sia in grado di ottenere patch di sicurezza per loro ...

SSL 2 was deprecated in 2011

Non è stato deprecato, era assolutamente vietato che rappresenta un'enorme differenza. Vedi anche Qual è la differenza tra SSLv3 deprecato e SSLv2 vietato?

However many devices are manufactured before 2011 and still in use today

TLS 1.0 è stato definito 1999 ed era disponibile nei principali stack TLS (incluso openssl) da questo momento. Non supportarlo non era già un'opzione nel 2011.

if a well-designed network service provides SSL 2 compatibility

È una sorta di affermazione contraddittoria: ben progettato contro la compatibilità SSLv2. Avere un dispositivo SSLv2 in rete non è solo insicuro a causa del protocollo SSLv2 stesso, ma anche perché è altamente probabile che qualsiasi vecchio dispositivo che non può parlare meglio di SSLv2 voglia usare anche codici deboli . / p>

if SSL 2 is not provided, the service will be completely inaccessible a major portion of devices (30~40%) that are otherwise perfectly functional.

A seconda dell'ambiente, potresti essere in grado di proteggere tali dispositivi aggiungendo alcuni software in primo piano in modo che siano disponibili con protocolli e crittografie migliori.

An example would be a corporate email server for daily communications.

Se questo server supporta solo SSLv2, deve essere così vecchio da avere molte altre vulnerabilità . TLS 1.0 era già disponibile con Windows XP.

What exactly are the risks of accepting SSL 2 connections on the server?

Anche se è male avere SSLv2, è brutto avere SSLv2 in aggiunta ad altri protocolli. Vedi attacco DROWN per i dettagli su come la disponibilità di SSLv2 può aiutare a decrittografare correttamente le connessioni crittografate.

In breve:
se tutto questo viene fatto all'interno di una rete ristretta in cui non si ha attività malevole, l'uso di SSLv2 è probabilmente perfettamente sicuro come sarebbe del testo normale. Ma non appena hai la possibilità che qualcuno attacchi la rete, devi affrontare i problemi causati dalla versione SSL non sicura ( DROWN ) e dall'età dello stack SSL ( cifrate deboli ) e anche i problemi generali del software (es. software obsoleto e probabilmente vulnerabile ).

How insecure would it be, today, if a well-designed network service provides SSL 2 compatibility?

estremamente insicuri , come menzionato da altri. Se i dati non sono davvero importanti come affermi e devi assolutamente supportare quei dispositivi obsoleti, sarebbe molto meglio consentire solo connessioni TLS sicure con il 60% dei tuoi client aggiornati e utilizzare la connessione in testo normale per altro 40% che sarebbe comunque insicuro.

In questo modo, quando le connessioni vengono compromesse, avrai solo il 40% dei danni da ripulire ... Bonus aggiuntivi ci saranno iniziative migliori per aggiornare i vecchi dispositivi in quanto le persone non (erroneamente) pensano che lì è "almeno un po 'di sicurezza con SSL2" (non c'è).

EDIT: This is not a question about how SSLv2 is insecure or why it should not be used. It is about the business risk associated with provide SSLv2 as an additional supported protocol for device compatibility. The concerned devices are:

1. Perfectly functional.
2. Supports only SSLv2. There are no possible software upgrade paths as these are not computers.
3. The only other alternative on these devices is a plaintext transmission.
4. Represent a majority (or non negligible portion) of the devices using the service.

I'm evaluating the whether to replace all devices, or continue using them but in a relatively insecure manner. It is therefore a business risk management decision. However I must first understand the business risks of providing SSLv2.

Ci sono due rischi aziendali:

1. Puoi esporre altri client (TLS) agli attacchi DROWN (che sono stati ben coperti da altre risposte quindi non li ripeterò qui)
2. Puoi far credere erroneamente ai tuoi utenti che i loro dati siano più sicuri di quanto sarebbe se fossero trasmessi in testo semplice.

Il testo normale sarebbe effettivamente più sicuro perché eliminerebbe (1) e attenuerebbe (2) (nella misura in cui gli utenti sono consapevoli di utilizzare un testo in chiaro).

(Tecnicamente, montare un attacco contro una sessione di testo in chiaro sarebbe più diretto che attaccare SSLv2, ma generalmente il modello di minaccia non dovrebbe assumere che l'avversario sia pigro, quindi non possiamo considerare SSLv2 più sicuro. )