TLS_FALLBACK_SCSV sarà la soluzione per i server che desiderano mantenere SSLv3 abilitato? In caso contrario, quali azioni vengono intraprese, se ce ne sono, che risolvono la vulnerabilità oltre a disabilitare SSLv3?
Il protocollo SSLv3 è difettoso. Questo non può essere risolto. In genere, un utente malintenzionato potrebbe sfruttarlo forzando la vittima a connettersi a un server utilizzando SSLv3 forzando le connessioni utilizzando protocolli più elevati per non riuscire. TLS_FALLBACK_SCSV tenta di impedire al browser / server di tornare a SSLv3 se è già stato provato un protocollo più alto.
Come puoi vedere, TLS_FALLBACK_SCSV non risolve il problema del protocollo, ma cerca di ridurre la superficie di attacco rendendo più difficile per l'attaccante forzare la vittima a eseguire il downgrade del protocollo.
TLS_FALLBACK_SCSV non avrà alcun effetto se il browser o il server non supportano qualcosa di superiore a SSLv3 (il che è raro, te lo concedo, ma non impossibile).
Ci sono state alcune discussioni sulla mitigazione dei problemi con alcune suddivisioni del record. Vale a dire, ciò che rende Poodle efficiente è che il padding può utilizzare fino a un blocco completo (8 byte con 3DES o RC2, 16 byte con AES). Quando ciò accade, solo l'ultimo byte del blocco viene controllato dal destinatario, che è il motivo per cui l'alterazione da parte dell'attaccante passa attraverso la probabilità 1/256. Quindi, se puoi fare in modo che la situazione di riempimento non si verifichi mai, puoi ridurre la probabilità di successo dell'attaccante.
L'idea è quindi, quando un record deve essere crittografato e porterebbe a un blocco finale con troppi padding casuali e troppo pochi byte non ignorati, a dividere i dati in due record, le cui lunghezze individuali indurranno gli ultimi blocchi con pochi byte di riempimento ignorati.
Questa "correzione" è discussa lì (vedi in particolare il commento 13). Il successo dell'attaccante scende da 1/256 a 1/281474976710656. Tuttavia, questo si applica solo a Barboncino come è stato descritto; ed è risaputo che la suddivisione dei record, sebbene "legale" dal punto di vista standard, può rompere vecchie, buggy, implementazioni legacy.
TLS_FALLBACK_SCSV dos non corregge SSL 3.0; corregge gli attacchi di downgrade del protocollo. Assicura che se il client e il server conoscono entrambi TLS 1.0+, non saranno obbligati a utilizzare SSL 3.0. Tuttavia, se il client o il server conosce solo SSL 3.0, la comunicazione utilizzerà SSL 3.0 e potrebbero essere applicati gli attacchi di Poodle. Ciò è inevitabile: se il server conosce solo SSL 3.0, la scelta è tra l'utilizzo di un protocollo vulnerabile di Poodle o la mancata comunicazione.
Un numero di persone ha espresso che preferirebbe quest'ultimo. Piuttosto che tollerare lo standard SSL 3.0 con TLS_FALLBACK_SCSV o con la suddivisione di record, lascialo morire. Dovrà accadere ad un certo punto; la preoccupazione generale innescata da una vulnerabilità potrebbe essere una buona occasione per questo.
Leggi altre domande sui tag encryption attacks tls protocols cipher-selection