Perché non possiamo fare attacchi MiTM quando si utilizza la connessione protetta

Il motivo per cui un utente malintenzionato non può utilizzare i cookie crittografati è che HTTPS crittografa l'intera conversazione HTTP tra client e server, non solo i cookie. (A meno che l'autore dell'attacco non sia riuscito a sovvertire le parti di scambio chiave del protocollo, ma questa è una storia per un'altra domanda.)

Per un esercizio divertente, utilizza sia Wireshark che il debugger del tuo browser per guardare il traffico di rete quando visiti il tuo sito HTTPS preferito.

Perché non riesci a individuare i cookie, e anche se potessi, non potresti riutilizzarli.

Una richiesta HTTP effettiva assomiglia a questo, e l'intera cosa è crittografata:

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Accept: text/html,application/xhtml+xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36 OPR/18.0.1284.49
Referer: http://en.wikipedia.org/wiki/Main_Page
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: centralnotice_bucket=0-4.2; uls-previous-languages=%5B%22en%22%5D
Connection: keep-alive

Si noti che il cookie è mescolato con un sacco di altre cose. Non puoi prendere un cookie crittografato perché non riesci a trovarlo (è circondato da elementi che variano da browser a browser e persino richiesta di richiesta). Anche se è possibile trovarlo, SSL include misure per impedire a un utente malintenzionato di inviare nuovamente una richiesta (un attacco di riproduzione ), e include un codice di autenticazione dei messaggi (MAC) per impedire a un utente malintenzionato di dividere una richiesta e usarne solo una parte.

Inoltre, SSL utilizza una chiave di crittografia diversa per ogni connessione. Anche se potessi prendere i cookie crittografati e bypassare il MAC, scopriresti che sono stati crittografati con la chiave sbagliata per poterli utilizzare.

Se qualcuno riuscisse a ottenere il cookie, ad esempio, riuscendo a ottenere i dati direttamente dal browser o dalle risorse umane (magari sedendosi al computer quando si alza e si allontana), potrebbero sicuramente riutilizzare il proprio cookie e funzionerebbe.

Un utente malintenzionato non può vedere i cookie perché https crittografa l'intero pacchetto http e il cookie viene inviato come parte del pacchetto.

Per inciso, un altro metodo che gli utenti malintenzionati possono utilizzare è quello di cercare di ingannare il browser e di inviare il cookie al server tramite http. (Google sslstrip se sei interessato a maggiori dettagli sull'attacco). Per evitare che questi server possano contrassegnare un cookie con il flag "sicuro" che indica al browser di trasmettere il cookie solo tramite una connessione SSL sicura.