Man in the Middle (Mitm) Proxy with Https Support

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.

Can HTTPS connections be hijacked with a man-in-the-middle attack?

Fiddler describes it like this:

Q: The HTTPS protocol was designed to prevent traffic viewing and tampering. Given that, how can Fiddler2 debug HTTPS traffic?
A: Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.
Fiddler's certificate is not trusted by your web browser (since Fiddler is not a Trusted Root Certification authority), and hence while Fiddler2 is intercepting your traffic, you'll see a HTTPS error message in your browser, like so:

How to prevent HTTPS man-in-middle attack from the server side?

As a web application developer there is very little you can do about this.

This issue needs to be dealt with further down the stack.

If someone half way around the world wants to:

a. Put a false root CA on someone's computer

b. Issue a cert for your domain under that CA

c. Impersonate your site

d. Point someone's local DNS entry for your domain to a different ip

In none of the above steps is your application involved or consulted so this is where good network administration and security is important.

Aside from that, maybe there's a legitimate reason for someone to do just this locally on their personal network. Who am I to stop them?

This is essentially what corporate web proxy filters do and they are within their rights to do it.

As far as stopping someone malicious from taking the above steps thats something that needs to be put on the administrators of your customers machines.

Can a man in the middle attack on an https READ all the communication?

Yes and No, it depends on some other elements in game...

The answer is YES in the case where there's no SSL certificate!

How?

Let's consider the classic case where the 2 peers are Alice and Bob trying to communicate via HTTPs.

The MITM can get only the public key from Alice and Bob. Not the private keys. Even in the original situation, Alice can only encrypt information to Bob using Bob's public key and Bob can only encrypt information to Alice using Alice's public key.

What a "smart" MITM would do is to REPLACE the public keys that are delivered in the channel for each pair. In other words: Alice sends the key that Bob is supposed to receive. The MITM will intercept this key and not deliver it to Bob, but instead, he/she will replace by its own key (let's call the hacker key) and then deliver to Bob this hacker key.

The same thing above will happen in the other direction with the key that Bob is supposed to send to Alice.

Well... now both Alice and Bob received a hacker key and they THINK the key is the original from the other peer (because there is no certificate), but the original is kept by hacker.
Do you see? The hacker can just receive information from one of the sides and decrypt (because it was encrypted with the hacker's public key) and then re-encrypt with the original public key of the other side. Simple like that!

... BUT the answer is NO if there is an SSL certificate.

Why?

Because certificates exists exactly to solve this problem described above. It means, the public key coming from Alice/Bob can be verified by digital signatures if they in fact belong to Alice and Bob, so, if they are using an SSL certificate Alice and Bob are able to detected that some MITM swapped the original keys. How this works is out of scope of this question, but "as a short answer" both sites will have third-party certificates "pre-installed" that can be used to validate the authenticity of the public keys being exchanged.