Brief history… SSLv2 deployed in Netscape 1.1 (1995) Microsoft improved upon it… Netscape deployed SSLv3 –Most commonly deployed IETF introduced TLS –Similar, but incompatible… Here, we just say “SSL”!
Broad overview SSL runs on top of TCP, in a user-level process –Recall, does not require changes to the OS –Using TCP rather than UDP simplifies things Recall, this opens a potential DoS attack
Basic protocol flow Alice (client) sends “hello”, supported crypto, and nonce R A Bob (server) sends a certificate, selects crypto, and sends nonce R B Alice encrypts S with Bob’s public key –Alice/Bob derive key(s) from R A, R B, S –Must be careful about which encryption scheme is used!
Basic flow, continued… They each authenticate the initial handshake using the shared key(s) The keys are used to encrypt/authenticate all subsequent communication –Separate keys shared for encryption and authentication in each direction –Also for IVs… (but this is a flaw!) –Sequence numbers used to prevent replay
Note… As described, SSL only provides one-way authentication (server-to-client) Not generally common for clients to have public keys Can do mutual authentication over SSL using, e.g., a password –SSL also allows for clients to have public keys
Session resumption Because it was designed with http traffic in mind, one “session” can be used to derive many secure “connections” –Server assigns a session_id and stores that along with the session key –“Connection keys” can be derived from the session key (assumes the client remembers it) and fresh nonces –Can always re-derive a session key (expensive!)
Some attacks (and fixes) Man-in-the-middle can downgrade the acceptable crypto in Alice’s first message –One of the problems with negotiating crypto… –Fixed by authenticating handshake phase An adversary could also close a connection early (TCP close_connection_request was not integrity-protected) –Fixed by adding “finish” message which is authenticated