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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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:
These are less often used, since they are not suitable for parties which have no previous consent of common data:
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.