C'è un client desktop A che si collega al sito web W in una connessione https
A --> W
In qualche modo tra A e W, c'è un proxy G.
A --> G --> W
HTTPS si basa su crittografia a chiave pubblica / privata . Ciò significa fondamentalmente che esiste una coppia di chiavi: la chiave pubblica viene utilizzata per la crittografia e la chiave privata segreta è necessaria per la decrittografia.
Un certificato è fondamentalmente una chiave pubblica con un'etichetta che identifica il proprietario.
Quindi, quando il browser si connette a un server HTTPS, il server risponderà con il suo certificato. Il browser controlla se il certificato è valido :
Se una di queste condizioni non viene soddisfatta, l'utente viene informato del problema.
Dopo la verifica, il browser estrae la chiave pubblica e lo utilizza per crittografare alcune informazioni prima di inviarlo al server. Il server può decrittografarlo perché il server ha la chiave privata corrispondente .
In this case, will G be able to get the certificate which A previously got from W?
Sì, il certificato è la chiave pubblica con l'etichetta. Il server web lo invierà a chiunque si connetta ad esso.
If G can get the certificate, does that mean that G will be able to decrypt the data?
No. Il certificato contiene la chiave pubblica del server web . Il proxy dannoso non è in possesso della chiave privata corrispondente. Quindi se il proxy inoltra il vero certificato al client, non può decodificare le informazioni che il client invia al server web.
Il server proxy potrebbe provare a falsificare il certificato e fornire la propria chiave pubblica. Ciò, tuttavia, distruggerà la firma delle autorità di certificazione . Il browser avviserà del certificato non valido.
Se l'amministratore del tuo computer collabora , è possibile che un server proxy annidi le connessioni https. Viene utilizzato in alcune aziende per cercare virus e implementare linee guida di uso accettabile.
Un ente di certificazione locale è configurato e l'amministratore dice al tuo browser che questa CA è affidabile . Il server proxy utilizza questa CA per firmare i suoi certificati falsificati.
Ovviamente, l'utente tende a fare clic sugli avvisi di sicurezza.
Supponendo che gli utenti non facciano clic sugli avvisi CERT (e supponendo che tu stia eseguendo un client non modificato), la risposta è: No, il proxy non può decrittografare i dati .
Per una spiegazione dettagliata di come HTTPS impedisce a un man-in-the-middle di decrittografare il tuo traffico, vedi qualsiasi risorsa standard su SSL / TLS, ad esempio,
P.S. Il certificato è dati pubblici. Contiene la chiave pubblica del server e il nome del dominio, nessuno dei quali è segreto. L'osservazione del certificato non aiuta l'utente malintenzionato a decrittografare i dati. (Sì, il proxy può osservare il certificato, ma questo è innocuo.)
Da Blog tecnologico di Philipp C. Heckel con alcune modifiche alla luce:
While attacking unencrypted HTTP traffic can be done without having to deal with X.509 certificates and certificate authorities (CA), SSL-encrypted HTTPS connections encrypt every request and response between client and server end-to-end. And because the transferred data is encrypted with a shared secret, a middle man (or a proxy) cannot decipher the exchanged data packets. When the client opens an SSL/TLS connection to the secure web server, it verifies the server’s identity by checking two conditions: First, it checks whether its certificate was signed by a CA known to the client. And second, it makes sure that the common name (CN, also: host name) of the server matches the one it connects to. If both conditions are true, the client assumes the connection is secure.
In order to be able to sniff into the connection, Proxy server can act as a certificate authority, however, not a very trustworthy one: Instead of issuing certificates to actual persons or organizations, proxy dynamically generates certificates to whatever hostname is needed for a connection. If, for instance, a client wants to connect to https://www.facebook.com, proxy generates a certificate for “www.facebook.com” and signs it with its own CA. Provided that the client trusts this CA, both of the above mentioned conditions are true (trusted CA, same CN) — meaning that the client believes that the proxy server is in fact “www.facebook.com”. The figure below shows the request/response flow for this scenario. This mechanism is called transparent HTTPS proxying.
For this attack to work, there are a few conditions that must be met:
- Proxy server as standard gateway (HTTP and HTTPS): For both HTTP and HTTPS proxying, the proxy server must of course be able to intercept the IP packets — meaning that it must be somewhere along the way of the packet path. The easiest way to achieve this is to change the default gateway in the client device to the Proxy server address.
- Trusted Proxy CA (HTTPS only): For the HTTPS proxying to work, the client must know (and trust!) the proxy CA, i.e. the CA key file must be added to the trust store of the client.
If you’re interested in transparently sniffing plain SSL sockets, you might want to try
SSLsplit, a transparent TLS/SSL man-in-the-middle proxy. There are many ways to attack SSL, but you don't need fake SSL certificates, a rogue Certification Authority (CA), or variations on security expert Moxie Marlinspike's man-in-the-middle SSL attacks. Why go to all that trouble when you can just buy a SSL interception proxy, such as Blue Coat Systems' ProxySG or their recently acquired Netronome SSL appliance to do the job for you?
Da Steven J. Vaughan- Nichols su ZDNet (estratto):
Blue Coat, the biggest name in the SSL interception business, is far from the only one offering SSL interception and breaking in a box. Until recently, for example, Microsoft would sell you a program, Forefront Threat Management Gateway 2010, which could do the job for you as well. With an SSL interception proxy program or device in place, here's what really happens:
If your company has set up the proxy correctly you won't know anything is off because they'll have arranged to have the proxy's internal SSL certificate registered on your machine as a valid certificate. If not, you'll receive a pop-up error message, which, if you click on to continue, will accept the "fake" digital certificate. In either case, you get a secure connection to the proxy, it gets a secure connection to the outside site -- and everything sent over the proxy can be read in plain text. Whoops.
A seconda della configurazione della rete sulla quale ci si trova, potrebbe essere possibile per gli amministratori visualizzare il contenuto delle connessioni HTTPS (e possibilmente VPN).
Ovviamente è possibile intercettare il traffico sulla rete, ma il solito problema è che non possono emettere certificati validi per tutti i siti che visiti, quindi visualizzerai molti avvisi di certificato ogni volta che accedi a un HTTPS sito, se provano a decodificare il traffico per guardarlo.
Tuttavia, se si utilizza un computer fornito dalla società, è possibile installare una nuova autorità di certificazione e utilizzarla per creare certificati SSL per i siti visitati, quindi non si presenterebbe come un problema.
Con il lato VPN delle cose potrebbe essere più complesso se la VPN non usa SSL, ma vale la stessa teoria. Se accedi a Internet da una macchina di proprietà di qualcun altro su una rete che controllano, è probabile che acceda a qualsiasi contenuto inserito.
Se stai cercando di evitare questo tipo di problema, utilizzerei un dispositivo che possiedi / controllo per accedere a Internet, in questo modo dovresti essere avvisato se si verifica un'intercettazione SSL.
Esatto, gli amministratori della rete aziendale implementano un attacco man-in-the-middle contro il client TLS con la propria CA in modo che possano vedere cosa lascia la loro rete. Probabilmente avranno un dispositivo che creerà un certificato al volo valido per gmail.com quando visiti gmail.com. Il motivo per cui lo fanno non è quello di interpretare il Dr. Evil, è così che possano difendersi dai segreti commerciali che vengono portati fuori dal loro edificio attraverso la loro connessione Internet. Seriamente, non fare il tuo private banking su un computer di lavoro.
Se si utilizza un prodotto software che non utilizza l'archivio certificati di sistema (ad esempio, un'istanza OpenVPN), quindi, no, non possono intercettare e decodificare il traffico perché non si fida della propria CA. Ad esempio, potresti ottenere lo stesso risultato usando un'app portatile di Firefox. E nella maggior parte dei browser puoi controllare i dettagli della tua connessione sicura e vedere chi è la CA, per sapere chi sta ascoltando o meno.
Il proxy può bloccare https e consentire solo http dal browser. Quindi può avviare la propria connessione https per passare le richieste al server.
La maggior parte degli utenti non se ne accorgerà.
L'HSTS dovrebbe fermarlo ma non è ampiamente utilizzato.
La terminazione SSL oi prodotti proxy SSL come Bluecoat devono essere sulla tua rete e considerando il costo, le procedure di installazione coinvolte e la normale politica di sicurezza che ogni organizzazione dovrebbe avere chi installa questi prodotti - le minacce di un utente malintenzionato che utilizza un SSL commerciale il prodotto di terminazione è quasi zero. OTOH: un insider di fiducia con accesso al NOC (network operations center) potrebbe infatti monitorare il traffico terminato da SSL e divulgare informazioni sensibili.
Questa è una preoccupazione comune (giustificata o meno) per le aziende che implementano sistemi DLP.
TUTTAVIA HA DETTO TUTTO QUESTO - c'è un altro vettore di attacco che è comune nello spazio dell'home banking che non richiede un proxy di rete ed è un attacco piggback / shim nel browser - dal momento che il DOM ha accesso al traffico di testo trasparente prima colpisce il tubo SSL - questo è un vettore di attacco conveniente e viene spesso installato tramite un'estensione del browser. C'è un eccellente articolo di Stackexchange su shim - È possibile installare uno shim (noto anche come polyfill) in IE, FF o Chrome senza che l'utente ne sia a conoscenza e può leggere le password immesse dall'utente in una pagina di accesso?
Leggi altre domande sui tag tls certificates sniffer
