Protezione bias RC4 con padding in TLS

Question

Protezione bias RC4 con padding in TLS

#1 da (9 voti)
#2 da (5 voti)

10

Sulla risposta a la mia precedente domanda sulle vulnerabilità di RC4 in TLS , Thomas Pornin ha dato una grande risposta, in cui ha detto:

One way to "fix" RC4, which has been suggested many times, is to drop the first 256 (or 512 or 1536 or whatever) bytes of output, since these are the most biased of them (the graphics in the slides show that quite clearly). But this would not be compatible with RC4-as-we-know-it

Curioso di questo e di un commento su HN che fornisce un suggerimento interessante, mi chiedo se il browser ( o anche un plug-in del browser) può riempire le richieste HTTP, in modo che i primi 256 byte (o 512 o qualsiasi altra cosa) siano solo un'intestazione inutile. per es.

GET / HTTP/1.1
X-Padding-Header: <256 bytes of random text>
Accept: */*
...

Per quanto ne so, le intestazioni sconosciute vengono ignorate (?), e questo assicurerebbe che i primi byte nella richiesta siano entrambi inutili (nessun valore nell'indovinarli) e casuali.

È una soluzione sciocca che potrebbe creare più danni che benefici? O se i browser lo risolvono potrebbero anche aggiornare a TLS 1.2?

(ps ovviamente se l'URL stesso contiene informazioni sensibili ed è abbastanza lungo, sarà presente nella richiesta prima dell'intestazione, quindi questa "protezione" potrebbe non essere di aiuto con questo, ma forse è sufficiente per proteggere i cookie ?)

web-browser tls rc4

posta Yoav Aner 13.03.2013 - 09:37

fonte

2 risposte

5

Questo sarebbe sicuro contro tutti gli attacchi che conosco.

Dal punto di vista della sicurezza, non è del tutto equivalente a eliminare i primi 256 o 512 byte. Con la tua proposta, l'utente malintenzionato ha un testo in chiaro noto (ad esempio, dalla riga GET e dall'intestazione X-Padding), mentre se si rilasciano i primi 256 byte, l'utente malintenzionato non ottiene il testo in chiaro in quelle posizioni. Teoricamente, se la conoscenza di alcuni dei primi 256 byte di output di RC4 consentisse a un utente malintenzionato di recuperare la chiave, allora il tuo schema sarebbe insufficiente. Tuttavia, non sono a conoscenza di alcun attacco su RC4 di quella forma. In pratica, tutti gli attacchi noti su RC4 dicono che uno o due dei primi byte di output di RC4 sono leggermente distorti, quindi non nascondono il testo in chiaro abbastanza bene come si vorrebbe - ma questo pregiudizio non consentire a un utente malintenzionato di dedurre la chiave RC4. Quindi, dal punto di vista della sicurezza, in pratica, il tuo schema è probabilmente tanto buono quanto quello di eliminare i primi 256 byte dell'output di RC4.

Tuttavia ... dal punto di vista delle prestazioni, hai appena aggiunto 256 byte alla richiesta ogni inviata tramite SSL. È molto brutto per le prestazioni. Questo problema di prestazioni è abbastanza probabile da uccidere questa proposta; probabilmente non è un candidato valido per la distribuzione.

Se i browser vogliono ripararlo, sarebbe molto meglio semplicemente aggiornare a TLS 1.2 e crittografie più sicure.

risposta data 13.03.2013 - 09:46

fonte

Leggi altre domande sui tag web-browser tls rc4

Un utente malintenzionato può "simulare" un indirizzo IP privato? Il campo della password deve essere cancellato dopo un tentativo di accesso non riuscito?

score 9 · Accepted Answer

Come @ D.W. sottolinea che ciò funzionerebbe - per proteggere il cookie . Il percorso viene prima delle intestazioni e può anche essere a rischio, se contiene dati sensibili in un luogo prevedibile (questo non è un caso comune al giorno d'oggi, ma la riscrittura degli URL per la gestione delle sessioni era popolare ).

Una variante apparirebbe così:

GET / HTTP/1.1
X-Header-Padding1: <X random padding bytes>
Accept: */*
Cookie: ...
...
X-Header-Padding2: <Y random padding bytes>

Scegliendo X e Y in modo casuale, ma in modo che X+Y sia corretto, la collocazione del cookie nello stream cambierebbe tra le richieste, in un modo che gli autori di attacchi non possono rilevare (poiché la lunghezza totale del le intestazioni sono costanti). Anche se non è così soddisfacente come semplicemente facendo cadere i primi 256 byte della richiesta, questo dovrebbe essere sufficiente per riportare lo sforzo degli attacchi basati su bias a miliardi di richieste, invece che a milioni, e potrebbe essere fatto con meno di 256 extra byte per richiesta (con X+Y = 32 dovrebbe farlo).