Se l'integrità non è stata mantenuta, un utente malintenzionato potrebbe modificare le pagine Web in transito e, ad esempio, modificare il codice Javascript contenuto in queste pagine. La crittografia, di per sé, non impedisce le alterazioni relativamente precise, a condizione che l'autore dell'attacco abbia qualche idea su quali siano i dati crittografati. Nella maggior parte dei contesti Web, l'utente malintenzionato può anche registrarsi come utente normale, in modo da poter visualizzare la struttura delle pagine Web ottenute dagli utenti normali.
Quando la connessione utilizza RC4 , viene generato un flusso pseudocasuale dipendente dalla chiave e XORed, bit a bit, con i dati da crittografare. Pertanto, se l'utente malintenzionato "indovina" che un determinato byte è la crittografia di una "A" (codice ASCII 0x41) e vuole renderlo la crittografia di una "m" (codice ASCII 0x6D), allora deve solo eseguire XOR byte crittografato con 0x2C (che è lo XOR di 0x41 con 0x6D) per ottenere un altro byte crittografato che, dopo la decrittazione, produrrà un 'm' invece di un 'A'. Nient'altro potrebbe essere influenzato; quindi, con la crittografia RC4, le alterazioni chirurgiche sono facili.
Con un codice a blocchi in modalità CBC , le cose sono meno facili per l'attaccante ma può ancora commettere un male: se vuole modificare un byte specifico, può farlo, ma questo manipolerà il blocco precedente. In particolare, con un codice a blocchi, i dati sono una sequenza di blocchi di 8 o 16 byte (a seconda del codice: 8 byte per 3DES, 16 byte per AES). L'attaccante può modificare a piacimento un blocco, con precisione chirurgica, a condizione che conosca il valore iniziale di quel blocco e non si preoccupi di cambiare il blocco precedente in qualche ciarpame casuale incontrollabile.
Facciamo un esempio. Supponiamo che un sito Web abbia una pagina di accesso, con un modulo HTML, che assomigli a questa:
<form action="https://www.example.com/authenticate.php">
Login: <input type="text" name="login" /><br />
Password: <input type="password" name="password" /></br />
<input type="submit" name="Submit" />
</form>
So che è brutto; è solo un esempio. Quando l'utente fa clic sul pulsante "invia", il browser invia una richiesta POST alla pagina https://www.example.com/authenticate.php .
Supponiamo ora che questa pagina sia crittografata con CBC con 3DES (blocchi da 8 byte) e che sia "." di ".com" sembra essere all'inizio di un blocco. L'utente malintenzionato può quindi XOR gli 8 byte crittografati precedenti (i byte corrispondenti a .example ) con quanto segue:
00 01 0E 09 01 07 0D 5B
Sul browser della vittima, il modulo verrà decrittografato come:
<form action="https://www########.bad.fx/henticate.php">
Login: <input type="text" name="login" /><br />
Password: <input type="password" name="password" /></br />
<input type="submit" name="Submit" />
</form>
Dove "########" saranno alcuni byte casuali. A condizione che nessuno di essi sia uno zero o un doppio preventivo (le probabilità che ciò accada siano bassi), il browser li considererà come parte dell'URL di destinazione. Il dominio bad.fx è controllato dall'attaccante (il TLD "fx" in realtà non esiste, sentiti libero di sostituirlo con il tuo preferito "TLD for Evil people"); il DNS dell'aggressore reindirizza allegramente tutte richieste per qualsiasi .bad.fx all'indirizzo IP del suo server; e l'attaccante ha acquistato (completamente legalmente) un certificato con caratteri jolly per "* .bad.fx". Quando l'utente inserisce la sua password, il suo browser si connette al sito Web controllato dagli aggressori, fa il protocollo SSL, è perfettamente contento del certificato dell'attaccante (supponendo che nessuno dei '#' sia un punto, di nuovo, è probabile), e invia la password.
Fortunatamente , SSL include una strong protezione dell'integrità, che impedisce tali attacchi. Con crittografie stream come RC4 e cifrari a blocchi in modalità CBC, la protezione dell'integrità utilizza HMAC ; le versioni più recenti di TLS possono anche utilizzare cifrari a blocchi nella modalità GCM , che integra una protezione dell'integrità altrettanto buona. Se l'attaccante ha tentato una delle acrobazie descritte sopra, il client (browser Web) rileverà l'alterazione e protesta e rifiuterà di utilizzare la pagina decrittografata. Vedi lo standard , sezione 6.2.3.