Il software client che è suscettibile di downgrade degli attacchi è difettoso, nel senso che fa di proposito cose al di fuori dello standard per supportare il software del server che è difettoso.
Normalmente, il client annuncia (nel ClientHello ) il suo numero di versione del protocollo supportato più alto (es. "3.2" per significare "TLS 1.1") e quindi il server risponde (nel ServerHello ) con la versione del protocollo che sarà usato per quella connessione. Pertanto, il comportamento teorico quando un client recente comunica con un server precedente è il seguente:
- Il cliente dice: "Supporto fino a 3.2".
- Il server pensa: "Mmh, non ho idea di cosa possa essere SSL 3.2, ma so che SSL 3.0 e 3.0 sono meno di 3.2".
- Il server risponde: "Useremo 3.0".
Tuttavia, in alcuni rari casi, in pratica, il vecchio software server non è solo vecchio ma rotto; e le cose vanno così:
- Il cliente dice: "Supporto fino a 3.2".
- Il server pensa: "OMG 3.2 NON HO IDEA CHE COSA DEVO IMPEGNARE SEPPUKU ONORABILE". Il server chiude bruscamente la connessione.
- Il cliente pensa: "Mmh, il server si è rotto, probabilmente un vecchio pezzo di spazzatura, devo usare la pazienza quando parlo agli anziani".
- Il client si ricollega e dice: "Supporto fino a 3.0".
- Il server risponde: "Useremo 3.0".
Quando le cose vanno in questo modo, l'hash che viene calcolato su tutti i messaggi di handshake e incluso nei messaggi Finished non include il fatto che il client possa aver utilizzato un protocollo più recente. Ricollegando e utilizzando una versione annunciata artificialmente inferiore, il client impedisce il funzionamento del sistema di rilevamento del downgrade. Possiamo dire che il problema si verifica perché i client non agiscono come dovrebbero, ma lo fanno perché ci sono server distribuiti che sono ancora più rotti. Qui può essere difficile dare la colpa senza ambiguità.
Gli autori di attacchi che vogliono forzare un protocollo eseguono il downgrade dell'abuso di quel sistema eliminando la prima connessione con un pacchetto RST ben piazzato, in modo da simulare un server senile che non tollera nessuno di questi discorsi su una versione di protocollo diversa dalla 3.0.
Il TLS Fallback Signaling Cipher Suite Value (SCSV) per la prevenzione degli attacchi di downgrade del protocollo extension, attualmente in bozza, è un metodo per intrufolarsi nel messaggio di handshake le informazioni che il veramente veramente supporta meglio di SSL 3.0, in un modo che non farà spargere il cervello elettronico ai vecchi server sul pavimento; assume la forma di uno speciale identificatore della suite di cifratura (si basa sull'idea che anche i vecchi server danneggiati non impazziranno quando l'elenco delle suite di crittografia supportate include uno che non conoscono). Naturalmente, il meccanismo offre protezione solo se entrambi il client e il server ne sono a conoscenza (il client deve inserire l'identificatore speciale e il server deve riconoscerlo e dire a se stesso: "come mai stanno facendo SSL 3.0 se il client conosce una versione più recente? Questo è fishy ... ").
Un altro punto di vista sull'argomento è che se SSL 3.0 è debole e non dovrebbe essere usato affatto, allora l'unica sana abitudine è rifiutarla del tutto. È necessaria una protezione contro gli attacchi di downgrade solo se si è ancora pronti a utilizzare SSL 3.0 nel caso in cui il server non supporti nient'altro. Se temi le conseguenze dell'utilizzo di SSL 3.0, dovresti non accettare di usarlo. Questo è considerato come potenzialmente estremo; potrebbe essere un compromesso più fluido, lato client (browser), per mantenere un elenco esplicito di server per cui SSL 3.0 sarà tollerato. Tale elenco, configurabile dall'utente stesso, combina la tolleranza possibile di alcuni sistemi legacy, e una buona dose di puntamento del dito nei sistemi la cui miseria avrebbe dovuto essere conclusa molto tempo fa.
Modifica: vedi i commenti lì ; questa è una discussione tra i manutentori di Firefox in cui discutono esattamente le conseguenze della caduta del supporto SSL 3.0 del tutto e varie alternative.