Remaining slides for lecture 26

CMSC 414
Computer (and Network) Security
Lecture 26
Jonathan Katz
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
– 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
 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
 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”)
 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 /
 Can be simplified somewhat if the user
chooses to do so…
Summary of course