CMSC 414 Computer (and Network) Security Lecture 26 Jonathan Katz SSL/TLS 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 RA Bob (server) sends a certificate, selects crypto, and sends nonce RB Alice encrypts S with Bob’s public key – Alice/Bob derive key(s) from RA, RB, 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 PGP Overview There are many schemes for “secure email” PGP is popular for a number of reasons… – …one of which is its PKI model (i.e., the “web of trust”) Overview PGP provides for both encryption and digital signatures Encryption – Standard techniques… – Multiple recipients handled efficiently Signatures – Again, standard techniques… “Web of trust” Anarchy model User defined level of trust in any signature / principal Can be simplified somewhat if the user chooses to do so… Summary of course