Come è possibile fare TLS tramite proxy senza che nessuno se ne accorga?

Dalla versione 1.1, HTTP supporta un metodo speciale, CONNECT. Questo imposta il tunnel TLS attraverso il proxy, anche se il tuo computer si collega direttamente al proxy. HTTPS sa come eseguire il tunneling dell'handshake TLS anche attraverso il proxy.

Vedi Wikipedia :

The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.

Ancora più dettagli qui :

A variation of HTTP tunneling when behind an HTTP Proxy Server is to use the "CONNECT" HTTP method.
In this mechanism, the client asks an HTTP Proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client. Note that only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection.
This mechanism is how a client behind an HTTP proxy can access websites using SSL (i.e. HTTPS).

Ma nota questo avvertimento:

Not all HTTP Proxy Servers support this feature, and even those that do, may limit the behaviour (for example only allowing connections to the default HTTPS port 443, or blocking traffic which doesn't appear to be SSL).

Normalmente, quando HTTPS viene eseguito tramite un proxy, questo viene fatto con il meccanismo CONNECT : il il client parla al proxy e gli chiede di fornire un tunnel bidirezionale per byte con il sistema di destinazione. In tal caso, il certificato che il client vede proviene realmente dal server, non dal proxy. In tale situazione, il proxy viene mantenuto all'esterno della sessione SSL / TLS: può vedere che alcuni SSL / TLS sono in corso, ma non ha accesso alle chiavi di crittografia.

Alcune organizzazioni implementano un Man-in-the-Middle completo generando al volo un falso certificato per il server di destinazione. Fanno così precisamente in modo che il proxy possa vedere i dati in chiaro e scansionarli in conformità alla politica dell'organizzazione (ad esempio scansione antivirus automatica). Questo può funzionare solo se il client (il tuo browser) accetta il certificato falso come originale, che a sua volta richiede che una CA radice controllata dall'organizzazione speciale venga spinto sul computer client (e in un mondo Windows / Active Directory, un GPO può fare quello).

Informazioni su tutti i principali fornitori di dispositivi firewall / proxy offrono tale meccanismo come opzione.

Non tutte le organizzazioni implementano un tale sistema MitM, per diversi motivi, tra cui:

• Il MitM automatico può essere costoso. L'appliance proxy potrebbe essere potente dal punto di vista computazionale se ci sono molti utenti; e la licenza del prodotto può essere elevata.

• MitM interrompe l'autenticazione del client basata su certificato.

• Fare un MitM ha senso solo se controlli effettivamente i dati, il che aumenta di nuovo i costi computazionali.

• Il push automatico di una CA radice non funziona con BYOD .

• Di norma, gli utenti non amano tali MitM.