ECDHE_RSA and gmail

Question

I'm using Chrome on Ubuntu Linux to connect to Gmail. The connection info says that ECDHE_RSA is used for the https symmetric key exchange.

Based on my understanding of TLS and Gmail, my client creates a symmetrical key, encrypts with Google's public key listed in its certificate, and then sends to Google. Since my browser recognizes Google's certificate, is it safe to assume that my connection is safe and cannot be compromised by a man in the middle attack? How could a man in the middle ever view the symmetric key since he doesn't have Google's private key to decrypt the message?

I do not have a certificate imported into my browser. I used Wireshark to snoop the TLS negotiation. I see in my "client hello" packet I send info on which cipher suites my client supports, a random number, and elliptical curve info. After the gmail server responds with a "server hello" and "certificate, server key exchange, server hello done", my client then sends "client key exchange, change cipher spec, encrypted handshake message". Is it right to assume that the symmetric key that is encrypted with Google's public key is in this packet under the "encrypted handshake message" (TLSv1.1 Record Layer: Handshake Protocol: Encrypted Handshake Message).

Is there any way a server could fingerprint (i.e. uniquely identify) my client in a future TCP connection on a different network via the symmetric key that my client generated above?

Answer 1

With ECDHE_RSA, the actual key exchange uses Elliptic Curve Diffie-Hellman; the ECDH public key of the server is not in its certificate, but in the ServerKeyExchange message, which the server signs with its private key (and your browser verifies that signature relatively to the public key which is in the server certificate). The symmetric key which results from ECDH is not "chosen" by the client alone, but it is still a key shared by client and server, and none other. That's less direct than your description, but your idea is correct: indeed, as long as the implementation is correct and your browser properly validates the server certificate, the exchanged data will be safe from eavesdroppers, impersonations and malicious alterations.

If your client tries to reconnect to the same server (this is normal in a Web context, since servers tend to drop connections after 15 seconds of inactivity), it will try to reuse the symmetric key from ECDH, so as to avoid the whole asymmetric cryptography business, and, more importantly, to avoid one network roundtrip. This is the abbreviated handshake of SSL/TLS. If both client and server still remember the previous connection (called "the SSL session"), then this will work. Under these conditions, the server could potentially recognize the client as being "the same as previously".

However, SSL session parameters (the negotiated symmetric key) are not stored in a permanent storage area, and are subject to forgetfulness. If you close your browser, it will forget all such sessions. An Apache server will, by default, remember SSL session parameters for 5 minutes, or possibly less if it handles many connections (since its storage space for such parameters has a configurable but finite size).

See this answer for a detailed walk-through of the SSL protocol.