SNI rivela l'host virtuale durante la query CONNECT a un proxy HTTPS?

La risposta non corretta alla tua domanda è: sì, SNI rivela il nome dell'host di destinazione al proxy. Ma, per essere più completo:

• Come indica @Steffen, il metodo CONNECT di solito funziona con i nomi host. Il client potrebbe richiedere una connessione con un indirizzo IP di destinazione o un altro nome host che si risolve (tramite il DNS) sullo stesso indirizzo IP, ma i client di solito non lo fanno.

• Una volta stabilita la connessione, il proxy deve inoltrare tutti i byte di dati avanti e indietro, il che implica, in particolare, che il proxy vede tutti i byte. Se viene utilizzato SNI , il messaggio di handshake ClientHello dal client conterrà il nome host del server di destinazione.

  Si può notare, in particolare, che un proxy potrebbe "ritardare" l'invio. Come da RFC, quando il proxy risponde alla richiesta CONNECT, si suppone che abbia già parlato con il server di destinazione; ma un proxy un po 'ingannevole potrebbe rivendicare che il server è stato contattato e attendere che il messaggio ClientHello del client esegua la connessione effettiva. Questo (teoricamente) consente di inviare richieste a diversi server effettivi in base al nome host di destinazione.

• In ogni caso, il server risponderà con i propri messaggi di handshake, incluso il Certificate . Questo viene inviato, necessariamente, prima che avvenga qualsiasi crittografia. Il certificato del server conterrà il nome del server (il client lo verifica ) quindi, indipendentemente da SNI, il server il nome non può essere considerato un segreto ben conservato.

Ciò che è crittografato è qualunque cosa viene inviata dopo l'handshake, cioè le intestazioni HTTP. Ma tutte le cose del proxy succedono prima, e l'handshake SSL stesso contiene dati non criptati.

Ora forse la tua domanda riguarda situazioni in cui la connessione al proxy utilizza SSL, e il nemico è un intercettatore tra il client e il proxy, non il proxy stesso. In tal caso, il nemico non vedrà il nome dell'host di destinazione. Il nemico vedrà l'handshake SSL, con SNI, tra il client e il proxy e SNI mostrerà il nome proxy a quel livello. Una volta stabilito il tunnel, tutto ciò che accade tra client e proxy è abbastanza opaco per l'avversario (anche se sarà comunque in grado di fare una buona ipotesi sulla dimensione degli scambi di dati).

Come è stato sottolineato, le richieste DNS potrebbero essere rivelatrici. Un client tipico dovrà prima risolvere il nome di destinazione per decidere se si tratta di un server "locale" o "non locale", quest'ultimo gestito attraverso il proxy. Pertanto, è probabile che il client prima urlhi il nome del server di destinazione, non crittografato e fuori da qualsiasi contesto SSL. È probabilmente possibile configurare il proxy in modo che tali perdite non si verifichino, ma può richiedere un certo sforzo. Una soluzione di proxy più completa (VPN, SOCK proxy su SSH ...) può essere più efficace nel nascondere i nomi dei siti che sfogli dai tuoi colleghi / colleghi / qualunque.

Mentre una richiesta CONNECT può essere eseguita con un IP di destinazione (ad esempio, il nome host risolto dal client) di solito viene eseguito con il nome host di destinazione (e il proxy verrà risolto dal nome host). Lo stesso nome viene quindi inviato di nuovo in chiaro nel messaggio di benvenuto del client quando si avvia l'handshake SSL.