Is HTTPS secure if someone snoops the initial handshake?

Question

Let's say I'm on an open wireless network that's being actively sniffed and I connect to an HTTPS site. Even though my subsequent traffic is encrypted, couldn't the sniffer use the data from the initial (non-secure) handshake to decrypt my subsequent data?

Answer 1

The SSL and TLS protocols (on which HTTPS is based) are designed in a way that no attacker (neither a passive nor an active one) can read anything of the encrypted part (if the cryptographic assumptions hold - and if you don't use the NONE cipher, which does no encryption).

Of course, the attacker can read the negotiation part. But this part will not contain anything which is (with current known algorithms) usable for cryptanalysis of the rest.

There are several possible algorithms to negotiate a secret session key - which one is chosen depends on which protocol suites (= set of algorithms to use) the client offers and what the server selects from these. Then we use the exchanged key to encrypt the rest of the connection using a symmetric algorithm.

Some popular key exchange mechanisms are these:

• Diffie-Hellman key exchange (DHE): Here both sides select random numbers a and b, calculate and exchange g^b or g^a, and then both calculate (g^b)^a = (g^a)^b, which is the same value. An attacker does not see a or b, only g^a and g^b, and can't derive from this the values. (All these calculations are done in some group, the multiplicative group modulo a big prime number for "normal" Diffie-Hellman, or in an elliptic curve group for ECDHE.)

  In the usual case of authenticated key exchange, afterwards the server signs some hash of all the negotiation data with his private key, which the client can then check using the public key. (This avoids active man-in-the-middle attacks, where the attacker negotiates one key with the server and another one with the client, then forwarding the data.) For anonymous connections there is no such step (and MITM is possible).

• assymetric encryption based (RSA key exchange): The client generates a random pre-master-secret, encrypts it using the public key of the server, and sends this to the server. The server can decrypt it an now both know the same pre-master secret. Applying a hash on this gives the master secret used for actual encryption (and the MAC).

  The problem is that a leak of the private key here compromises all past connections (where this key was used and which where registered), while with Diffie-Hellman only future connections are affected (where the attacker can launch a MITM-attack).

These are less often used, since they are not suitable for parties which have no previous consent of common data:

• password based, for example the Secure Remote Password protocol: This works similar to Diffie-Hellman (i.e. it uses exponentiation in a prime group - but addition and multiplication, too.). The server has a password verifier v, s (with s once selected random, and v = g^(H(s,p))), the client has the password p.

  To authenticate (and exchange a key), the client sends the user name and A = g^a (where a is random data), the server sends back s and B = k·v + g^b (with b random and k some fixed parameter). Both calculate then u = H(A,B). Then the client calculates S = (B - k·g^(H(s,p)))^(a+u·x), while the server calculates S = (A·v^u)^b. If the password is right, these are identical. To obtain the key itself, both calculate K = H(S).

• Pre-shared key, as defined in RFC 4279: This is a bunch of algorithms based on some pre-shared secret key common between both parties. (Obviously this is of no use in the anonymous internet.)

  The PSK method simply transfers some key identifier (which is not nearer specified - it will depend on the application, i.e. higher level protocol which is using this), and both then derive the master session key from this shared secret.

  The DHE_PSK uses a Diffie-Hellman key exchange as described above, and this key is then hashed together with the pre-shared key to form the master session key.

  For RSA_PSK the client sends an RSA-encrypted random data, together with the key ID - the premaster secret is then formed from the descrypted random data, together with the pre-shared key.

Answer 2

Yes, it is. Because of the way public key crypto works, they wouldn't be able to decrypt it.

First, realize that something encrypted with a public key can only be decrypted with the corresponding private key (or, depending on the algorithm, vice-versa).

So lets say everyone (including the sniffer) has the server's public key. You encrypt something with it, and send it to the server. The sniffer doesn't have the private key, so they can't decrypt it.

To make sure you do, in fact, have the server's public key, you use secure certificates. I'm not going to go into detail, but let's just say that if you have a valid certificate, there is almost no chance someone will get whatever it is that you are sending.