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

Question

I'm using gmail from work, but I need to enter a password for a proxy when accesing the first web page. The password is asked from inside the browser. I receive a certificate from the proxy which I must accept in order to make the Internet connection work.

Can my HTTPS connection, between gmail and browser, be tracked in this situation?

Solution 1

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:

Solution 2

tracked? Well even though https encrypts the traffic you still know the ip address of both parties (gmail and the browser). HTTPS doesn't solve this problem, but a different blend of crypto has created The Onion Router(TOR) which does make impossible to locate both servers and clients.

Under "normal" conditions when an attacker is trying to MITM HTTPS your browser should throw a certificate error. This is the whole point of SSL backed by a PKI. HOWEVER in 2009 Moxie Marlenspike gave a killer Blackhat talk in which he was able to MITM HTTPS without warning. His tools is called SSLStrip, and I highly recommend watching that video.

A good solution to SSLStrip was developed by Google. Its called STS, and you should enable this on all of your web applications. Currently sts is only supported by Chrome, but Firefox is working on their supporting this feature. Eventually all browsers should support it.

Solution 3

Yes they can. You can see this for yourself by downloading Fiddler and using it to decrypt https traffic. Fiddler issues its own certificate and acts a man in the middle. You would need to view the certificate in your browser to see whether it is actually issued by gmail.

Solution 4

It seems that the renegotiation is a weak spot in the TSLv1 (see TLS renegotiation attack. More bad news for SSL).

View more solutions

Comments

[Martin Smith]

Superuser might be a better forum for this question though I think it is of interest to anyone developing https sites. And just to mention prefixing a question "Debate:" is probably a sure fire way of getting it closed as subjective and argumentative!

[Henri]

It is, but it is not really relevant here.

[Martin Smith]

The OP says "I receive from the proxy a certificate which I must accept in order to make the Internet connection work." I presume that browser -> proxy is https encrypted using that certificate. Not gmail's. It is then decrypted at the proxy and re encrypted when doing the https request to gmail. It should be possible to see this though by clicking the padlock icon and viewing the certificate.

[Henri]

This doesnt proof that you can perform a man in the middle on https, perhaps fiddler can do this because it resides inside the browser. In that case it is no longer called a man-in-the-middle attack but a man-in-the-browser attack (no kidding). If fiddler does not depend on residing in the browser, can you please provide more details on how this can be done? and how fidler does this

[Martin Smith]

@Henri - See my comment to your answer.

[Martin Smith]

+1. And of course if you accept the fiddler certificate then you won't see the HTTPS error message.

[Martin Smith]

From the question: "I receive from the proxy a certificate which I must accept in order to make the Internet connection work."

[rook]

Yes, but fidderl's attack throws a warning so Https is doing its job. sslstrip can bypass this warning all together.

[rook]

Fiddler causes the browser to throw an error and thats the point of https. However sslstrip can bypass https without throwing an error. You should read my post.

[rook]

+1 much cooler attack than fiddler. sslstrip kicks ass! I saw his talk when I was at blackhat last year.

[rook]

@Henri you need to see Moxie Marlenspike's talk and then delete your comment.

[Martin Smith]

@The Rook It won't throw a warning for the OP as he has already accepted the certificate.

[Sripathi Krishnan]

Rook +1 for SSLStrip. It'd work 99% of the times, but if the user directly enters https:// in the browser, it won't work. SSLStrip only works if the first request to the server is over http.

[Myxtic]

@Rook - Totally agree with you. I spent a lot of time trying to suppress the untrusted ssl certificate warning using paros proxy and mitm proxy, but finally achieved it only using sslstrip.