Does https prevent man in the middle attacks by proxy server?
There is a desktop client A connecting to website W in a https connection
A --> W
Somehow between A and W, there is a proxy G.
A --> G --> W
- In this case, will G be able to get the certificate which A previously got from W?
- If G can get the certificate, does that mean that G will be able to decrypt the data?
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.
If the administrator and the computer cooperates, so there won't be certificate warnings. How can the user know if the proxy listens to the conversation? Afaik my company scans https, but I don't see the self signed certificate in the chain trust when I examine the certificates of https sites.
You can detect it. 1st your company certificate isn't a self signed one. It is a certificate duly signed by an authority wich is automagically embedded within all the Internet Explorer of the world. To detect all **magic** certificates allowances without your notice, there is one uniq but hard path. Remove all the magically authorized root certificates within your Internet Explorer. From this starting point, you will have to accept explictly **all servers certificates** . You will have to read, understand them, and accept the ones you **trust**.
one question is: I can't see what is leaving the network, but what about the response the server sent back to browser, now I have public key, does that mean I can decode all the responses and I saw all what the browser is seeing ?
Public key only allows you to encrypt data, and is only used for the session key negotiation. (@Hendrik you might maybe improve the part about the usage of the public key by the browser)
Anyone who's able to generate a certificate for the proxy that is signed using a signing-cert of any ca trusted by your computer will be able to intercept your connection. Are there any RFCs / tech out that is able to prevent this? I'm aware of some plugins that provide a cert fingerprint db and warn you if the cert fingerprint YOU get is not the same the plugin server gets but those also might be intercepted. Althought https proxies are today only used in companies as you described this opens up ways for mitm attacks for attackers with enough influance to get their hands on trusted CAs.
@masi There is a project called Certificate Patrol that keeps track of previously seen certificates and can alert you if a certificate changes unexpectedly. It's not useful in the corporate context described above but could be useful on a mobile device to alert you when your local network is hostile.
And what about the response the W sends back to A? Will G be able to read it?
@se7entyse7en no. Just like how W has a private key, A also establishes such a key at the start of communication. G has neither of these keys.
@zinking No, you can't, public/private key is only used to create a session key and that session key is used to encrypt/decrypt all traffic between https client/server as symmetric encryption is must faster.
Good article. Thanks. I have one question: Before session key negotiation, can `G` capture the public key from the web server and proceed a session key negotiation earlier than `A` does, so that he can act as `A`?
@Jeon, the public key (and the certificate information) is public, so anyone can grab it. But during the TLS handshake, the server has to proof that it knows the associated private key. At some point the client will encrypt a piece of unguessable information with the public key, and the server has to decrypt it with its private key to continue the handshake. Please see the Wikipedia article on the TLS for details.
Can you add more information here: "destroy the signature of the certification authorities". So why can't `G` serve his public key to `A` and spoof the certificate in a way that it is correctly signed with it's own private key? So is it double signed, once by `W` and once by `the truzsted certificate provider` and `A` knows this public key as well.
Another case that undermines the concept can be forms of preinstalled bloatware. The most prominent case I can remember being Lenovo installing "SuperFish". Though ultimately this is just the equivalent of "the administrator cooperates", though in this case unknowingly.
Note that newer versions of Firefox will display `Connection verified by a certificate issuer that is not recognized by Mozilla.` for non-NSS-approved certs, so (unlike Chrome and IE) current COTS TLS proxies can be noticed by a Firefox user with just 1 click of forensic investigation.