Lecture 17: SSL/TLS

1. Lecture 17: SSL/TLS • history, architecture • basic handshake • session initiation/resumption • key computation • negotiating cipher suites • application: SET

2. History of SSL/TLS • SSL (secure socket layer) v2 • Released in 1995 with Netscape 1.1 • Key generation algorithm kept secret • Reverse engineered & broken by Wagner & Goldberg • SSLv3 • Fixed and improved, released in 1996 • Public design process • PCT (private communications technology): Microsoft’s version of SSL • TLS (transport layer security): IETF’s version, yet to be deployed, incompatible with v2 and v3

3. SSL Architecture • Record Protocol: Message encryption/authentication • Handshake P.: Identity authentication & key exchange • Alert P.: Error notification (cryptographic or otherwise) • Change Cipher P.: Activate the pending crypto suite SSL Change Cipher Spec. Protocol SSL Handshake Protocol SSL Alert Protocol HTTP, etc. SSL Record Protocol TCP IP

4. Basic SSL/TLS Handshake Protocol • SSL is on top of TCP: uses TCP’s character stream, breaks the stream into records with headers and encrypts to provide: encrypted and integrity protected stream to the upper layers hello, crypto offered, RA certificate, crypto selected, RB {S}Bob, {keyed hash of messages} Alice Bob (K = f(S, RA, RB)) {keyed hash of messages} session keys derived from K • who is authenticated in this exchange? • Bob can optionally send “certificate request” in message 2 to authenticate Alice, not currently deployed

5. Session Initiation • session vs. connection: “sessions” are relatively long-lived. Multiple “connections” (TCP) can be supported under the same SSL session. (designed for HTTP 1.0) without costly public key operations • if Bob wants to resume session later (have multiple connections) – he sends Alice session_id and stores <session_id, key> crypto offered, RA session-id, mycert, crypto selected, RB, {keyed hash of msgs} {S}B,{keyed hash of messages} Alice Bob {keyed hash of messages} session keys derived from K, RA, RB

6. Session Resumption(Connection Establishment) • Alice sends session-id, if Bob remembers, new connection (keys) can be established (session resumed) by just exchanging nonces • is connection resumption stateless? session-id, crypto offered, RA session-id, crypto selected, RB, {keyed hash of msgs} Alice Bob {keyed hash of messages} session keys derived from K, RA, RB

7. Key Computation • “pre-master key”: S • “master key”: K = f(S, RA, RB) • For each connection, 6 keys are generated from K and the nonces (two more Rs). • 3 keys for each direction: encryption, integrity, IV – why do we need separate keys for encryption and integrity protection? • may be unnecessarily complex but gets the job done

8. Negotiating Cipher Suites • Cipher suite: A complete package specifying the crypto to be used. (encryption algorithm, key length, integrity algorithm, etc.) • 24 (v2) to 16 (v3 and TLS) bits is reserved to id the cipher suites • ~30 predefined standard cipher suites. • 256 values reserved for private use. • Selection: • v2: Alice proposes a set of suites; Bob returns a subset of them; Alice selects one (which doesn’t make much sense) • v3: Alice proposes a set of suites; Bob selects one.

9. The Trust Model • PKI: Oligarchy model with X.509 certificates • Browsers come configured with a set of trusted root CAs (VeriSign, AT&T, Entrust/Nortel, etc.)Additions to the root CA list by user is possible. • Typically, only the server is authenticated.Client authentication is optional. • No certificate revocation mechanism.Even expiration dates are not enforced.

10. Attacks on v2 • downgrade attack – no integrity protection for the list of requested cipher suites; attacker can force parties to use weaker crypto • in v3, at the end of the handshake (protected) Bob and Alice exchange a “finished” messages which contains the digest of the previous messages • truncation attack – SSL depended on TCP for closing connection; attacker can close connectivity by sending TCP close message • v3 added a “finished” message to indicate there is no more data to be sent

11. Secure Electronic Transaction (SET) • Application-layer e-commerce protocol • Developed by Visa & MasterCard consortium, 1996 • officially supported by Visa in 2003 • Provides security, authentication, order transaction, payment authorization, etc. • Both the merchant & customer are authenticated by X.509 certificates

12. SET • Problems of e-commerce over SSL/TLS: • malicious merchants (stealing credit card numbers) • malicious customers (using stolen credit card no.s) • SET solution: • Bank (B) acts as an intermediary between the customer (C) & the merchant (M) • M forwards C’s info. to B, encrypted with B’s key • B does: • authenticate C’s public key signature • decrypt the transaction info. (amount, card number, etc.) • issue payment authorization & send it to B • more on that in next slide

13. SET Dual Signature • concerns • merchant needs to know order information (OI) only • bank needs to know payment information (PI) only • needs to be a way to bind both kinds of info without revealing it to the wrong party • dual sig by customer • customer’s private key {H{H{PI} || H{OI}}} = dual signature (DS) • merchant can verify the info when it has OI and H{PI} and customer’s public key (how?) • bank can verify the info when it has PI, H{OI} and customer’s public key