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?
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.
It seems that the renegotiation is a weak spot in the TSLv1 (see TLS renegotiation attack. More bad news for SSL).
It cannot be tracked between the gmail webserver and your pc, but once it is inside the pc, it can be tracked. I dont understand how two people claim that https can be tracked with mitm since the whole purpose of https is to prevent such attacks.
The point is that all HTTP level messages are encrypted, and mac-ed. Due to the certificate trust chain, you cannot fake a certificate, so it should not be possible to perform a man in the middle.
The ones who claim it is possible, can you please give details about how and why it is possible and how the existing countermeasures are circumvented?
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:
As pointed out by other answers (read also here) for this to work really "in the middle" (i.e. excluding the cases in which the capturing occurs at one of the end-points, inside the browser or inside the web server), some kind of proxy must be set, who speaks to your browser and to the server, pretending to both to be the other side. But your browser (and ssl) is smart enough to realize that the certificate that the proxy sends you ("saying: I am gmail") is illegal, i.e. is not signed by a trusted Root Certification authority. Then, this will only work if the user explicitly accepts that untrusted certificate, or if the CA used by the proxy was inserted into the trusted CA registry in his browser.
In summary, if the user is using a clean/trusted browser installation, and if he refuses certificates issued by untrusted authorities, an man "in the middle" cannot decrypt an https communication.
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.