Ho patchato il mio server con OpenSSL 1.0.1j per la vulnerabilità di Poodle. Ho letto le specifiche su TLS_FALLBACK_SCSV. Da quello che posso dire per far funzionare correttamente la prevenzione del fallback TLS, è necessario che il client lo annuncino nel client hello e, in caso contrario, anche se il server supporta il fallback, non verrà utilizzato. Qual è il comportamento previsto se solo un lato, ad esempio il lato server, lo supporta solo?
Questo è corretto: i client che non supportano TLS_FALLBACK_SCSV non possono beneficiare dell'implementazione del server. Tuttavia, capire l'intento della funzione può aiutarti a mettere la tua mente a tuo agio.
Esistono 2 categorie di implementazioni TLS / SSL: moderne e legacy. Le moderne implementazioni utilizzano versioni recenti di TLS (sebbene possano essere bloccate in versioni precedenti come TLS 1.1) e possono essere aggiornate con il supporto per estensioni aggiuntive. Il codice richiesto per aggiungere il supporto TLS_FALLBACK_SCSV in una libreria TLS è enormemente più piccolo e più semplice dell'applicazione di una nuova versione TLS.
Le implementazioni legacy non possono essere aggiornate, ma potrebbe dover essere supportata per vari motivi pratici. TLS_FALLBACK_SCSV consente alle implementazioni moderne di supportare i protocolli legacy senza essere obbligati a usarli quando entrambi gli endpoint possono supportare un protocollo migliore.
Quindi la comunicazione con un'implementazione legacy non è mai protetta, presumibilmente perché non supporta comunque le versioni TLS più recenti. Ovviamente, il metodo più sicuro sarebbe disabilitare tutti tranne la versione più recente di TLS, ma ciò renderebbe inaccessibile una grande porzione di servizi TLS. TLS_FALLBACK_SCSV è un buon modo (una volta ampiamente adottato) per consentire la connettività legacy quando necessario, impedendo comunque che le implementazioni moderne vengano declassate da un man-in-the-middle che può rilasciare pacchetti selezionati.
Per rispondere direttamente alla tua domanda, l'SCSV viene inviato solo dal cliente. Come pseudo-ciphersuite, non può mai essere "scelto" dal server e il server non può scegliere un valore che il client non ha inviato. Quindi un client che non supporta TLS_FALLBACK_SCSV non lo invierà, anche se l'handshake è un fallback di una versione superiore e il server non si comporterà diversamente. Un client che supporta SCSV e sperimenta un fallback lo invierà come uno dei valori di ciphersuite supportati; un server non conforme selezionerà semplicemente una delle altre ciphersuites che supporta, ignorando il valore sconosciuto.
P.S. TLS_FALLBACK_SCSV era precedentemente chiamato TLS_DOWNGRADE_SCSV in un progetto di RFC precedente, che indica il suo scopo nel prevenire gli attacchi di downgrade. Presumo che sia stato rinominato per indicare l'azione che il client sta effettivamente prendendo: ricorrere a una versione precedente del protocollo a causa di un errore di handshake.
Leggi altre domande sui tag openssl attacks tls cipher-selection