Does https prevent man in the middle attacks by proxy server?
How does HTTPS work?
HTTPS is based on public/private-key cryptography. This basically means that there is a key pair: The public key is used for encryption and the secret private key is required for decryption.
A certificate is basically a public key with a label identifying the owner.
So when your browser connects to an HTTPS server, the server will answer with its certificate. The browser checks if the certificate is valid:
- the owner information need to match the server name that the user requested.
- the certificate needs to be signed by a trusted certification authority.
If one of these conditions is not met, the user is informed about the problem.
After the verification, the browser extracts the public key and uses it to encrypt some information before sending it to the server. The server can decrypt it because the server has the matching private key.
How does HTTPS prevent man in the middle attacks?
In this case, will G be able to get the certificate which A previously got from W?
Yes, the certificate is the public key with the label. The webserver will send it to anyone who connects to it.
If G can get the certificate, does that mean that G will be able to decrypt the data?
No. The certificate contains the public key of the webserver. The malicious proxy is not in the possession of the matching private key. So if the proxy forwards the real certificate to the client, it cannot decrypt information the client sends to the webserver.
The proxy server may try to forge the certificate and provide his own public key instead. This will, however, destroy the signature of the certification authorities. The browser will warn about the invalid certificate.
Is there a way a proxy server can read HTTPS?
If the administrator of your computer cooperates, it is possible for a proxy server to sniff https connections. This is used in some companies in order to scan for viruses and to enforce guidelines of acceptable use.
A local certification authority is setup and the administrator tells your browser that this CA is trustworthy. The proxy server uses this CA to sign his forged certificates.
Oh and of course, user tend to click security warnings away.
Assuming that users do not click through cert warnings (and assuming that you are running an unmodified client), the answer is: No, the proxy cannot decrypt the data.
For a detailed explanation of how HTTPS prevents a man-in-the-middle from decrypting your traffic, see any standard resource on SSL/TLS, e.g.,
How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?
Wikipedia page on TLS
P.S. The certificate is public data. It contains the server's public key and domain name, neither of which are secret. Observing the certificate does not help the attacker to decrypt the data. (Yes, the proxy can observe the certificate, but this is harmless.)
From Philipp C. Heckel's tech blog with some light edits:
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?
From Steven J. Vaughan-Nichols on ZDNet (excerpted):
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.
