Secondo il seguente documento, it è possibile decrittografare il traffico HTTPS ispezionando le chiamate AJAX e utilizzando il parametro size come oracle crittografico.
Should I be sending a variable length payload alongside every HTTPS GET or POST? Is that sufficient in protecting myself from this attack?
Should the HTTPS response have a variable length string appended as well?
How large should that random appendage of random length data be?
Dall'esterno, si può solo vedere la lunghezza dei dati scambiati, cioè la lunghezza totale della richiesta, e la lunghezza totale della risposta (arrotondata a un multiplo del blocco di cifratura simmetrica dimensione, ad esempio 16 byte se viene utilizzato AES, ma non arrotondato affatto con RC4). Per evitare la perdita di informazioni, tutte le richieste e tutte le risposte devono avere esattamente la stessa dimensione; quindi il padding dovrebbe avere una dimensione variabile che dipende dalla lunghezza dei dati imbottiti . Se aggiungi padding con una lunghezza casuale ma con una distribuzione di probabilità che non dipende dalla dimensione della richiesta o della risposta, la lunghezza della richiesta originale può essere ricostruita statisticamente se tale richiesta viene eseguita su base regolare.
Non è necessario che i byte del padding siano casuali. Solo la lunghezza è visibile "dall'esterno". Puoi usare valori di byte costanti (ad esempio un'intestazione HTTP personalizzata X-Padding: ZZZZZZZZZ con, come contenuto, una sequenza di 'Z' di lunghezza appropriata). Usando dati casuali potrebbe perdere effettivamente informazioni extra attraverso i tempi (se il generatore casuale non è molto veloce, l'attaccante potrebbe osservare il tempo di reazione del client o del server e dedurre la dimensione del padding, ottenendo indirettamente il vero richiesta o lunghezza della risposta).
Puntare sempre su una dimensione fissa è uno spreco di larghezza di banda della rete, poiché tutte le richieste avranno le dimensioni della richiesta più grande possibile e tutte le risposte la dimensione della risposta più ampia possibile. @ Il suggerimento di Paŭlo di eseguire il padding fino al prossimo multiplo di un dato valore (ad es. Fino alla prossima lunghezza che è un multiplo di 500 byte) è appropriato: perde un po 'di più del padding sempre alla stessa lunghezza, ma non perde tanto; ed evita sprechi di risorse di rete.
Leggi altre domande sui tag random http ajax encryption tls