Con HTTPS, quali informazioni potrebbe attirare un MitM attacker?

Con MitM su un sito Web HTTPS, la più grande minaccia deriva dalla possibilità di sostituire il certificato SSL del sito con quello canaglia. Sì, l'utente riceverà un avviso che indica che il sito non corrisponde al certificato, ma è probabile che gli utenti facciano clic su Continua. Una volta che il certificato è stato sostituito, può decodificare tutte le comunicazioni poiché ha la chiave privata per il proprio certificato.

Se supponiamo che non sostituisca il certificato, hai ragione nel dire che non c'è molto che possa dedurre dall'ascolto della connessione. Credo che tu abbia coperto la maggior parte dei punti.

In una connessione SSL, la porzione GET o POST è crittografata. Ad esempio: visitatore: link

www.yoursite.com          visible 
GET /shoppingcart.aspx    encrypted
HTTP/1.0                  encrypted

Ciò a cui stai pensando è chiamato attacco di inferenza , dove con poche informazioni, un attaccante può mettere insieme pezzi di un puzzle. Quindi chiedi:

If the hacker knows what the site does and what is expected to be downloaded or posted to it, I would guess he'd be able to work out roughly what the user is doing just by the data size of each https request/response.

Questo non è necessariamente il caso. Di nuovo, poiché sia un GET che un POST sono crittografati, sarebbe un gioco di indovinelli senza valore in una certa misura. Considera quanto segue:

Esempio A

Site contains 1mb file called topsecret.docx
Visitor uploads a 1mb video of cats

Che cosa vedrai:

Site <--> 1mb session <--> Visitor

Poiché GET e POST sono entrambi crittografati, non è possibile determinare se l'utente ha scaricato o caricato. Tutto quello che stai vedendo è uno scambio di 1 MB. Qualsiasi attaccante perderebbe tempo e risorse per giocare a un gioco di ipotesi, tuttavia considera un terzo sito nel mix.

Esempio B

Site A contains 1mb file called topsecret.docx
Visitor does something
Visitor visits Site B
Site B now contains topsecret.docx

Che cosa vedrai (ovviamente tramite lo sniffing della rete):

   Visitor <--> Site A (1mb session)
   Visitor <--> Site B (1mb session)

Se potessi trovare gli stessi documenti su entrambi i siti, potresti dedurre che il visitatore è andato sul sito a, ha scaricato un file, quindi ha visitato il sito b dove è apparso il file. Potresti farlo per documentare ulteriormente la prova, tuttavia, dovresti trovare il file iniziale. In caso contrario, il visitatore potrebbe essere andato su entrambi i siti e caricato o scaricato i video dei gatti.

Sarebbe più facile per qualcuno con le risorse portare a termine questo tipo di attacco, a MiTM semplicemente i siti con cerotti rubati, sslstrip o qualche altro trucco contro un gioco di indovinelli.

RISPOSTA MODIFICATA

Lekensteyn, ho aggiunto un esempio fittizio per illustrare un punto. Ed è ancora vero, quindi ti darò un altro esempio

Il sito A contiene 2 file (File1 (1mb) e File2 (200mb)

Visitor <--> download File2 <--> SiteA 

In quanto sopra, il visitatore sta scaricando un file da 200 MB e all'avvio interrompe la sessione dicendo 1mb. Poiché non è possibile vedere ciò che ha fatto, l'analisi del traffico mostra che la sessione era una connessione 1 MB. Cosa vedrai:

Visitor <--> 1mb session <--> Site A

Saresti disposto a scommettere il tuo ultimo dollaro che il visitatore ha scaricato File1 in base alle dimensioni? Nel mio esempio, ho usato un meccanismo rozzo per illustrare la mia risposta. C'erano molte cose che avrei potuto ottenere nei dettagli, ma ho scelto di non farlo per brevità

The fact that the user is going to the site at all. I'm guessing that there would likely have been a DNS request for the domain name, and that request wouldn't have been encrypted, so the hacker knows at the very least that the user is accessing this specific site.

Sì, la richiesta DNS rivelerà il nome host se la richiesta DNS può essere MITM e l'IP di destinazione e la porta della connessione HTTPS sono anche visibili in chiaro per essere indirizzati al server. Se SNI è abilitato sul client, il nome del dominio viene anche trasmesso in chiaro, se non il SubjectAltNames restituiti nel certificato indicheranno o un nome di dominio, o una piccola lista di possibili nomi di dominio che potrebbero essere facili da restringere a seconda della conoscenza dell'attaccante potrebbe provenire da altre fonti.

URLs - Are the actual URLs of the request encrypted as well as the content? If not, some URLs may contain useful information for the attacker (ie which pages have been requested, ID numbers for requested data, etc)

Gli URL sono privati durante una sessione HTTPS. Quindi, se l'utente va a https://example.com:444/buyThing/thing.php?id=123 , sarebbe solo possibile che il MITM stabilisse che la destinazione era example.com sulla porta 444 su TLS.

The size of the transmitted data: If the hacker knows what the site does and what is expected to be downloaded or posted to it, I would guess he'd be able to work out roughly what the user is doing just by the data size of each https request/response. For instance, if the site's purpose is to allow users to download protected documents, the hacker could deduce which of the documents on the site the user has downloaded.

Sì, è possibile che la quantità di dati sia utilizzata in un attacco canale laterale .

Request/response timings: Similar to the above, if the hacker has knowledge of the site, and knows that a particular page has a slow response time, he would be able to deduce when the user went to that page.

Sì, questo è vero ed è come la vulnerabilità dei canali temporali / laterali descritta qui .

How much of the above is actually feasible? Would I be right to worry about them if I'm developing a sensitive site? Are there any other angles I haven't thought of?

Bene, sono tutti fattibili. Il nome di dominio rivelato è più un problema di privacy per l'individuo piuttosto che di sicurezza. Se loro stessi sono preoccupati di questo, dovrebbero usare un servizio come TOR.

Vedi questa risposta per alcuni dei miei altri approfondimenti su ciò che un MITM può essere in grado di vedere come URL nell'intestazione referer se questi dati sono gestiti male dal sito e / o dal browser.

Possono anche essere eseguiti altri tipi di attacchi da canale laterale come questi , come quando un completamento automatico su HTTPS può portare alla determinazione dei caratteri a causa delle ridotte dimensioni dei dati crittografati.