1. 1 Lecture 12 SSL/TLS (Secure Sockets Layer / Transport Layer Security) CIS 4362 - CIS 5357 Network Security

2. 2 The security provided by SSL SSL runs above layer 4 (the transport control layer), It is sometimes said to be at layer 4 In practice, SSL uses TCP sockets –The underlying TCP implementation handles robustness of communication, such as replay of lost packets, buffering packets to re-order them correctly, etc. SSL extends the TCP interface (sockets API) by adding security Versions 2 & 3, with SSLv3 most commonly deployed. TLS is a variation of v3

3. 3 What does it entail? To use SSL, applications must change. –They have to use the SSL API (application programming interface) and use SSL calls instead of TCP calls. Applications’ networking code must change SSL may be deployed without making changes to the underlying Operating System, because it does not alter the implementation of the TCP protocol.

4. 4 The rogue packet problem Dealing with running above TCP TCP uses checksums to ensure correctness of data. –but this checksum prevents only against random errors. Suppose an attacker to SSL: – Forges the next TCP packet (in a TCP connection, packets are numbered). – Re-computes the TCP checksum The TCP protocol accepts the corrupt packet, mark the packet number as delivered/received. TCP relays the corrupted packet to SSL –SSL checks its cryptographic checksum -- a message authentication code (MAC) -- and realizes that the packet has been forged

5. 5 The rogue packet problem continued TCP receives true packet from legitimate sender, sees that it has an already used number, and discards the packet as bad. –SSL cannot tell TCP to change its behavior, because it has not changed the TCP code. Only option for SSL is to hang up the connection. The result is as if the connection had been cut, and the attacker does not need to be “in the middle.” SSL/TLS decided to live with this problem, rather than re- implement TCP functionality above UDP

6. 6 SSL as software only Implementing SSL in hardware is unwieldy –It requires a TCP implementation to function –Therefore TCP has to be implemented in the same hardware –But TCP uses long buffers to ensure communication reliability. That means your hardware will require a lot of memory and be costly. If SSL worked at a lower level, say level 3/ network layer, it could be coded in a network card.

7. 7 Advantages of SSL Allows for portable implementation, because it is an application-level process –Suitable for bundling with applications such as browsers, can be installed with user-privileges only, and minimum expertise in anything. –SSL can authenticate users (end-to-end authentication), not only machines or IP addresses (link-to-link authentication)

8. 8 SSL/TLS: First Ingredients SSL supports several “cipher suites”: –Algorithm sets for public key encryption, symmetric key encryption, and authentication (MACs). –Flexibility was needed because of export restrictions. –Client and Server must negotiate which algorithms are used in a session. Client and server agree on a common secret: –Negotiated using public key cryptography –Incorporates challenges (nonces) from both parties. –From this common secret the symmetric keys are derived. SSL’s focus is on real-time communication security, for applications such as those requiring authentication of web sites but not specifically the authentication of clients

9. 9 SSL/TLS: Ingredients (2) SSL uses directional symmetric keys. After agreeing on a common secret (master key K): –Client and server derive from it two IVs, encrypt and decrypt keys, as well as authentication and verification keys. A total of six secrets are derived from the agreed secret (pre-key). –Client read keys = Server write keys Server IV = part of Server encryption parameters = part of client decryption parameters Server encryption key = Client decryption key Server authentication key = Client verification key (also called integrity keys or MAC keys) –Client write keys = Server read keys Client IV = part of Client encryption parameters = part of server decryption parameters Client encryption key = Server decryption key Client authentication key = Server verification key

10. 10 SSL/TLS Basic Protocol Client Server Cipher suites supported, R 1 = R Client Create S; Derive K as f(S,R 1,R 2 ) Get S; Derive K as f(S,R 1,R 2 ) Choice of cipher suite, R 2 = R Server {S} Server, MAC CAK ( handshake msgs ) MAC SAK ( handshake msgs ) Enc., auth. data

11. 11 Computing the Keys The random R’s are 32 bytes long, with the first 4 bytes being Unix time Master secret is 48 bytes, generated from the pre- master secret (typically also 48 bytes) and uses both the R’s: master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random));

12. 12 Generating the operational keys To generate the key material, compute key_block = MD5(master_secret + SHA(`A' + master_secret + ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA(`BB' + master_secret + ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA(`CCC' + master_secret + ServerHello.random + ClientHello.random)) + [...]; + is concatenation. As much of the key-block is used as is needed for the 6 keys (based on the specific cryptographic suite used)

13. 13 Some cipher suites CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 }; CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };

14. 14 Messages Exchanged Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data

15. 15 Encoding Record types 20 = ChangeCipherSpec 21 = Alert (notifications) 22 = handshake (handshake messages) 23 = application_data (encrypted and integrity protected Record header (never encrypted) 1 octet: record type 2 octets:version number 2 octets:length

16. 16 Encrypted & integrity protected records Compute HMAC, with integrity key, on Sequence number Record header Record data Result is (sequence number now not used): Record header record data HMAC pad Encrypt all but record header, with encryption key Record header encrypted & integrity protected record Record is sent to other side Note that many handshake messages can be in one record: these have their own formats