Lecture: Transport Layer Security (secure Socket Layer)

Transcription

1 Lecture: Transport Layer Security (secure Socket Layer) Recommended reading: Stephen Thomas, SSS and TLS essentials, Wiley, 2000 Very old and in some parts obsolete, but very well written

2 Lecture s twofold goal Full dissection of a well known and widely employed security protocol Rasonable in-depth analysis of TSL details Devil is in details Although many more details had to be skipped (this is not a full course on TLS ) Understand how a long-to-live security protocol should be designed Show good design choices vs bad ones TLS shows several examples for both!

3 Introduction to TLS

4 History of SSL/TLS SSL v1 by Netscape never released SSL v2 Integrated in netscape 1.1 Badly broken! SSL v3 Redesigned from scratch by Netscape TLS v1.0 First IETF design (versus Netscape) RFC 2246, jan 1999 TLS v 1.1 RFC 4346 Apr 2006 DTLS RFC 4347 Apr 2006 UDP support TLS = SSL with minor modification TLS1.0=SSLv3.1 However NOT backward compatible with SSL 3.0 TLS v 1.2 Still in progress Internet draft v07-bis (nov 07) Get rid of now weak MD5/SHA-1hash (negotiated PRF, default SHA-256) Public Domain implementation

5 SSL/TLS: layered view HTTP SMTP TCP/UDP/ANY HTTP https SMTP smtps SST/TLS IPsec IP Network layer security TCP (if UDP, then DTLS) IP Transport layer security SSL/TLS: operates on top of TCP, but below application layer (can be considered as top sublayer for L4 or bottom for L7) SSL/TLS: NOT a security enhancement of TCP! Not necessarily limited to Internet transport (L4)! Devised for point-to-point relationships in general E.g. EAP-TLS (RFC 2716) TLS mechanisms employed for authentication and integrity protection over L2 EAP

6 Application support HTTP http 80 TLS https 443 SMTP smtp 25 TLS smtps 587 TCP/IP HTTP http 80 Typical approach: reserve special port number for SSL/TLS mediated application Example: port 80 = HTTP over TCP Port 443 = HTTP over SSL/TLS (HTTPS) SSL/TLS common application port numbers smtps 465 (MS) or 587 (others) spop3 995 imaps 991 telnets 992 Pros works well; de facto standard Straightforward application support!! Cons: 2 reserved port numbers for same service deprecated by IETF (but still here ) Alternative approach: slightly adapt application s internals App reuses same port number Example: HTTPv1.1: upgrade: TLS/1.0 new http command (see RFC 2817)

7 TLS Goals Establish a session Agree on algorithms Share secrets Perform authentication Transfer application data Communication privacy Symmetric encryption Data integrity Keyed Message Authentication Code (HMAC) TLS approach: two-in-one Most other security protocols clearly distinguish the protocol for establishing a session (e.g., IPsec IKE) from the protocol that delivers data and enforces security services (e.g., IPsec ESP/AH)

8 Session vs Connection Connection: Transport service TLS provides encryption and integrity TLS Record Protocol Session: Association between Client and Server Authentication and exchange of security parameters May include several connections Heavy work: done once at the beginning Designed for HTTPv1.0; TLS Handshake Protocol

9 TLS protocol stack Trivial protocols! Error Handling HTTP, etc start cipher Establishes session & Initializes communicaton Data transfer Handshake Protocol Alert Protocol Change Cipher Spec TLS Record Protocol Application on TLS Possibly special app port# Minor modification of apps may be necessary (e.g. see RFC 2817/2818 for - HTTPS #443 - HTTPv1.1 ext TCP

10 TLS Record Protocol

11 Record Protocol operation Record Protocol: - takes messages to be transmitted from apps - fragments the data into manageable blocks - optionally compresses the data - applies a MAC - encrypts - and transmits the result. - Reverse operation at reception (decryption, verification, decompression, reassembly, delivery to apps)

12 Fragmentation At application TLS interface DON T get confused with TCP segmentation!! Input: block message of arbitrary size possibly multiple aggregated messages of SAME protocol Fragment size: 2 14 =16384 bytes

13 Compression Based on compression state negotiated Lossless compression, if size increases (may happen in special cases) increase must NOT exceed 1024 bytes but no compression by default Until recently, no compression was employed in TLS & SSLv3! Feature formerly used only in SSLv2 But some specifications recently emerged» RFC 3749 support for DEFLATE (RFC 1951)» RFC 3943 support for Lempel-Ziv-Stac Reason: widespread diffusion of verbose languages e.g. XML

14 Message Authentication Code MAC computation Secret (symmetric) key derived from security parameters negotiated during handshake Hash function: negotiated during handshake Computation: uses HMAC construction keyed-hashing Message Authentication, RFC 2104

15 Why HMAC? /1 Pay 100 dollars Pay 1000 dollars Pay 100 dollars H(M,S) Pay 1000 dollars H(M,S) Modified! Simplest way to authenticate a message: Share secret S Share Hash function H Compute H(message, secret) and verify upon reception Good hash (anticollision properties) good protection Weaker than digital signature, but practical

16 Why HMAC? /2 Practical question: how to insert a secret in the hash??? Secret prefix H(S M) may lead to extension attacks H(S M X) may be computed from H(S M) without knowing S If H(M)=H(M ) then H(M X)=H(M X) Secret suffix H(M S) much better;» but pre-computation can be exploited in attacks» and no formal proof of security Envelope H(S1 M S2) two secrets needed» Again, no formal security proof

17 HMAC RFC 2104, february 2007 HMAC K (M) = H(K + XOR opad H(K + XOR ipad M)) K + = shared key padded to hash basic block size» When H=MD5, padding to 512 bits opad = 0x36 = repeated as needed ipad = 0x5C = repeated as needed HMAC design goals: quantitatively proven robustness: as secure as its underlying hash is» see Bellare, Canetti, Krawcxykz, Keying Hash Functions for Message Authentication, 1996 Practical and flexible (you may change the underlying hash with more robust one) Efficient computation Padding: two key effect!

18 Encryption Fragment Encryption Applies to both (compressed) fragment and MAC No encryption possible If no encryption negotiated Or in early handshake phases Symmetric encryption algorithm Block or stream cipher Algorithm (RC4, DES, 3DES, etc) negotiated during handshake, too If block cipher, padding necessary to achieve block size Secret key derived from security parameters negotiated during handshake Differs from key used in MAC Encryption algorithm CANNOT increase size of more than 1024 bytes

19 Record Protocol Data Unit Application data OR Alert OR Handshake OR Change_cipher_spec 3.1 for TLS 5 bytes header Content type = 1 Version = 1+1 Length = 2 Content Type higher layer protocol 20 = 0x14 = Change Cipher Spec 21 = 0x15 = Alert 22 = 0x16 = Handshake 23 = 0x17 = Application Data Sequence number Not transmitted, but kept at both connection extremes Remember: reliable transport, hence no holes NO WAY TO AVOID TCP Explicit 2 (epoch = cipher state change) + 6 bytes sequence number were added in DTLS

20 MAC generation details Computed through HMAC HMAC(seq.num ctype version len data) Minor differences with SSLv3» No version in SSLv3» Slightly different HMAC construction (RFC 2104 final specification not yet finalized at the time ) Hash used in HMAC: MD5 16 bytes hash SHA-1 20 bytes hash Negotiation may decide not to use MAC In practice, always present Sequence number: Not transmitted but included in the MAC to detect missing/extra data and to prevent replay/reordering attacks

21 TLS Handshake Protocol

22 Handshake: when Initial negotiation and exchange of parameters (mutually) authenticate agree on algorithms exchange random values Exchange secrets or information to compute secrets session resumption Re-keying ( refresh secrets) Initial handshake Abbreviated handshake Includes auth & cert verification TCP conn TCP conn Abbreviated handshake TCP conn time TLS SESSION

23 Handshake: goals Secure negotiation of shared secrets Never transmitted in clear text; derived from crypto parameters exchanged Robust to MITM attacks if connection authenticated Optional authentication for both client and/or server in practice always required for server Through asymmetric, or public key, cryptography Exchange certificates and/or crypto information Reliable Negotiation: Attacker cannot tamper communication and affect/alter the negotiation outcome without being detected by the involved C&S parties Fundamental: negotiation amenable to downgrade attacks!!

24 CLIENT Client Hello Certificate Handshake Messages Client Key Exchange Certificate Verify Change Ciper Spec Finished Server Hello Certificate Server Key Exchange Certificate Request Server Hello Done Change Cipher Spec Finished SERVER Mandatory Optional and/or only at session start-up Start encryption Application Data

25 TCP segmentation (example) Handshake Layer Server Hello Certificate Server Hello Done TLS Record Layer Server Hello Certificate Server Hello Done TCP Layer Server Hello Certificate Certificate (continued) Server Hello Done Simplified example: server responds to client hello with certificate only Arbitrary correspondence between TLS Records and TCP segments (TLS records fragmented into TCP segments) Obvious! Do you remember TCP?

26 Handshake message format Incapsulated in TLS Record Handshake types: hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20) Handshake type Length of remaining message 3 bytes Depends on handshake msg Content type=0x16 Major version Minor version Length of fragment 2 bytes payload

27 Handshake phase 1 CLIENT Client Hello Server Hello SERVER General goal: Create TLS/SSL connection between client and server Detailed goals Agree on TLS/SSL version Define session ID Exchange nonces timestamp + random values used to, e.g., generate keys Agree on cipher algorithms Agree on compression algorithm

28 Client Hello First message, sent in plain text Incapsulated in 5 bytes TLS Record Content: Handshake Type (1 byte), Length (3 bytes), Version (2 bytes) Type 01 for Client Hello Version: 0300 for SSLv3, 0301 for TLS 32 bytes Random (4 bytes Timestamp + 28 bytes random) First 4 bytes in standard UNIX 32-bit format» Seconds since the midnight starting Jan 1, 1970, GMT (Session ID length, session ID) 1+32 bytes either empty or previous session ID» Previous session ID = resumed session state (Cipher Suites length, Cipher suites) 2+Nx2 bytes, in order of client preference (Compression length, compression algorithm) 1+1 byte (in all cases, today: compression algo = 00 = null)

29 PUBLIC-KEY ALGORITHM Cipher suites SYMMETRIC ALGORITHM HASH ALGORITHM TLS_AAAAAAA_WITH_BBBBBBBB_CCCCCCCC TLS_NULL_WITH_NULL_NULL INITIAL (NULL) CIPHER SUITE TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_DES_CBC_SHA JUST A FEW EXAMPLES (FULL LIST IN RFC) TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_RC4_128_MD5 Note: arbitrary combination not possible: must choose from a (small) list of combinations

30 The two basic approaches to key management Key transport (e.g., RSA) One party generates a random secret» Client in TLS Which is transported to the other party through a cryptographically secured channel» To Server» Using public key encryption CLIENT draw secret Public Key Pk Public Key Pk E Pk (secret) SERVER Key agreement (e.g., DH) Shared secred generated at both party sides through suitable exchange of crypto parameters CLIENT Y, g Y Compute mod p secret = (g X ) Y = g XY g, p, g X mod p g Y mod p SERVER Y, g Y Compute mod p secret = (g Y ) X = g XY

31 Selected from Client list Server Hello In reply to Client Hello, sent in plain text Content: Handshake Type (1 byte), Length (3 bytes) Type = 02 for Server Hello) Version Highest supported by both Client and Server 32 bytes Random (4 bytes Timestamp + 28 bytes random) Different random value than Client Hello (Session ID length, session ID) If Client session ID=0, then generate session ID Otherwise, if resumed session ID OK also for Server, use it; Otherwise generate new one Cipher Suite, 2 bytes Selected from client list (usually best one, but no obligation) Compression algo, 1 byte

32 Downgrade attack MITM doesn t break SSL3.x, but knows very well how to break SSL2.0 (40 bit encryption only) CLIENT SSLv3.1 Client Hello, SSLv3.1 Server Hello, SSLv2.0 Client Hello, SSLv2.0 Server Hello, SSLv2.0 SERVER SSL v3.1 Client assumes that Server supports only SSL 2.0!! Server assumes that client supports only SSL 2.0!! Downgrade attacks on cipher suites, too MITM: remove strong cipher suites, and leave in Client Hello only the ones he knows he can break! Since hello message authentication not viable at the moment (not yet a shared secret available), verification must be necessarily delayed to a subsequent phase

33 CLIENT Handshake phase 2 & 3 (schematic,, RSA case) Signed_ca(server, PublicKey) SERVER (SSLVersion SharedSecret) PublicKey Phase 2: Server sends authentication information (certificate) Along with Public Key (in certificate or in extra msg) Phase 3: Client generates a Shared Secret Length depends on agreed cipher suite (RSA = 46 bytes) And transmits it to Server, encrypted with Public Key Native SSL version included to early combat downgrade attacks

34 Against downgrade attack CLIENT SSLv3.1 Client Hello, SSLv3.1 Server Hello, SSLv2.0 Client Hello, SSLv2.0 Server Hello, v2.0 SERVER SSL v3.1 Signed_ca(server, PublicKey) (SSLv3.1 SharedSecret) PublicKey STOP!! Since (signed) certificate cannot be tampered and since MITM cannot decrypt SharedSecret and must act as pass-through Downgrade attack on SSL version easily discovered! Encrypted SSL version is the one initially proposed, NOT the one negotiated in server hello, of course

35 Handshake Phase 2 details CLIENT Certificate (single or certificate chain) Server Key Exchange Certificate Request (certificate type & certificate authorities) Server Hello Done SERVER Certificate typically a certificate chain Server Key exchange When certificate not issued (no server authentication required UNSAFE!!) When certificate key is for signature only (not for encryption) When certificate key cannot be used for legal reasons E.g. RSA key larger than 512 bits may not be used for encryption outside US, but only for signature Larger RSA key encoded in certificates may be used to sign shorter, temporary, RSA key When Ephemeral Diffie-Hellman used Certificate request Requires client authentication (asks for an acceptable certificate) Server Hello Done empty message

36 Example: Diffie-Hellman /1 Review of DH Server transmits public value g X mod p Client replies with public value g Y mod p Both compute shared key as K = (g Y ) X mod p = (g X ) Y mod p Three basic approaches (see next slide): Anonymous Fixed Ephemeral Depends on whether X and Y values are pre-assigned or dynamically generated and/or signed Anon & Ephemeral DH transmitted in ServerKeyExchange

37 Example: Diffie-Hellman /2 DH variants Anonymous (basic) Diffie-Hellman X, Y generated on the fly and NOT authenticated Trivial MITM attack C Y, g Y secret = g XY g, g Z g Y (Fixed) Diffie-Hellman DH public parameters g X and g Y are static and signed by a certification authority No MITM anymore But they are long-lived brute-force attacks Ephemeral Diffie-Hellman DH parameters can vary But unlike anonymous DH, they are SIGNED by the party Hence parties mush have an RSA or DSS secret key for signature purposes Hence, why don t just use RSA key transport? (we are here neglecting IPR/legal issues, of course ) MITM Z, g Z Secret with C = g YZ Secret with S = g XZ g, g X g Z S X, g X secret = g XZ

38 Example: Diffie-Hellman /3 ServerKeyExchange message format: Content type=0x14 Handshake type=0x0c Major version=3 DH p length 2 bytes DH g length 2 bytes DH Ys length 2 bytes Minor version=1 Length 3 bytes = nn-4 Length of fragment 2 bytes = nn DH p value *** DH g value *** DH Ys value *** TLS Record Header (5 bytes) 0x14 = Handshake protocol Handshake Header (4 bytes); 0x0c=ServerKeyEx DH parameters (variable length) Signature RSA 16 MD SHA-1 DSA 20 SHA-1 only Signature size and hash used depends on signature type (RSA or DSA). Note: RSA uses BOTH MD5 and SHA-1 Client replies with DH public value Ys only (p and g are already known by the Server )

39 Handshake Phase 3 details CLIENT Certificate Client Key Exchange Certificate Verify SERVER Certificate: Client certificate if requested Client Key exchange Transmit encrypted symmetric (premaster) key or information to generate secret key at server side (e.g. Diffie-Hellman Ys) Certificate Verify Signature of something known at both client and server ALL the messages exchanged up to now» Which is not only known, but also useful! Allows to detect at an early stage (more later on this) tampering attacks (e.g. cipher suite downgrade) To prove Client KNOWS the private key behind the certificate Otherwise I could authenticate by simply copying a certificate

40 A (smart) detail on certificate verify Q: Why Certificate Verify does not immediately follows certificate? A: to include connection specific crypto parameters into signature! client & server random values Explicit inclusion of master secret in SSLv3.0» Since master secret can be computed only after the ClientKeyExchange message, Certificate Verify follows ClientKeyExchange» Although this was abandoned in TLS1.x, but certificate verify still left as late as possible and hence after ClientKeyExchange

41 CLIENT Change Ciper Spec Finished Phase 4 Change Cipher Spec Finished SERVER Phase 4 has two fundamental goals Switch to the new security connection state Hence authentication and encryption based on keys computed with the exchanged security parameters Immediately applied to finished message» First check that everything went OK! If Client and(orserver cannot decrypt finished message, something has gone wrong! Authenticate all the previous handshake messages Finished = digital signature of all the previous handshake messages as transmitted and received by the peer up to now To avoid MITM tampering

42 Change Cipher Spec Defined as a separate protocol (!) Only one message: 1 single byte Fixed content: constant value = 01 (!!!) Change cipher spec protocol 01 Content type=0x14 Major version Minor version TLS Record Header Length of fragment 0x0001 payload Why a separate protocol, and not part of the Handshake? Wise choice! TLS specification allows aggregation of multiple messages of a SAME upper layer protocol into single TLS Record. How this possible with a Change Cipher Spec? (TLS Record is either ALL encrypted, or NOT encrypted)

43 TLS Key Computation

44 Secret hierarchy Pre Master Secret Exchanged (RSA) or computed (DH) during handshake - could be always the same value for same C-S pair (e.g., in the case fo fixed DH) Master Secret Connection State Keys Nonce C Nonce S Master Secret computed from: - Pre master - random values from C & S - timestamps from C & S Recomputed at session resumption Up to 6 keys: - encription keys (write/read = C/S) - authentication keys (write/read = C/S) - initialization vector if needed (write/read) Recomputed at session resumption

45 Abbreviated handshake (3-way) (session resumption) Used to re-generate key material For new connection Avoids to reauthenticate peers Done at start of session only Avoid to re-exchange pre-master-secret Exchange new TS+random values CLIENT Client Hello Server Hello SERVER Change Cipher Spec Finished Change Ciper Spec Finished Application Data

46 Initial keying, re-keying: todo 1) Add randomness in key generation Pre master nounces? Master key 2) Expand initially limited secret to the needed amount of crypto material A3547B6AF2??? FFA100F4579D5F3AB. Encryption key Blablabla key

47 Basic building block: PRF Input (seed, other) Pseudo Random Function Output ( random ), unlimited secret Fundamental brick : GOOD PRF Criteria and extensive literature available... Not only GOOD, but also fast/lightweight PRFs in TLS SSL 3.0: not fully satisfactory PRF TLS 1.0 and 1.1: good PRF but hard-coded! Construction used MD5 and SHA-1 (now weak) (unlike IPsec) TLS forgot that good in crypto is not forever. TLS 1.2:negotiable PRF (at last ), and strong default based on SHA-256

48 PRF from a 1-way hash: Expansion function P hash A0 = seed A1 = HMAC hash (A0) A2 = HMAC hash (A1) A3 = HMAC hash (A2) Same secret used in all HMACs Hash = chosen hash function P hash = HMAC hash (A 1 seed) HMAC hash (A 2 seed) HMAC hash (A 3 seed) P hash function of: Chosen hash function Secret seed P hash size: any (unlike HMAC size)

49 TLS 1.2 PRF from P hash PRF(secret, label, seed) = P hash (label seed) TLS1.2: Default: this construction with SHA bytes hash But also negotiable PRF Hence possibly very different and not based on HMAC Example: Master secret generation Inputs: Secret = Pre-master-secret Seed = Nonces (client-random & server-random) Further input: Label = string master secret Computation: first 48 bytes of: PRF(pre-master-secret, master secret, Client-Random Server-Random)

50 PRF (until( TLS 1.1, i.e. today!) Employs two hash algorithms Idea: combine both MD5 and SHA-1 Greater robustness! Must break both Indeed Input: Desired length Secret Assume even size, split it in two parts (S 1,S 2 ) Seed Label (an ascii string) Source: Stephen Thomas, SSL&TLS Essentials PRF(scrt, lbl, sd) = P MD5 (lbl sd) XOR P SHA-1 (lbl sd) MD5 uses S1 as secret SHA-1 uses S2 as secret

51 Key generation Master secret [48 bytes]: PRF(pre-master-secret, master secret, Client-Random Server-Random) Key Block [size depends on cipher suites]: PRF(master-secret, key expansion, Server-Random Client-Random) Individual keys: Partition key block into up to 6 fields in the following order: Client MAC, Server MAC, Client Key, Server Key, Client IV, Server IV PRF used also in computation of finished message instead of normal MD5 or SHA-1 Hash. E.g. For client finished message: PRF(master-secret, client finished, MD5(all handshake msg) SHA-1(all handshake msg)) [12 bytes]

52 TLS connection management & application support

53 Alert Protocol TLS defines special messages to convey alert information between the involved fields Alert Protocol messages encapsulated into TLS Records And accordingly encrypted/authenticated Alert Protocol format (2 bytes): First byte: Alert Level warning(1), fatal(02) Second Byte: Alert Description 23 possible alerts Alert protocol Alert level Alert description Content type=0x15 Major version Minor version TLS Record Header Length of fragment 0x0002 payload

54 Sample alerts See RFC2246 for all alerts and detailed description unexpected_message Inappropriate message received Fatal - should never be observed in communication between proper implementations bad_record_mac Record is received with an incorrect MAC Fatal record_overflow Record length exceeds bytes Fatal handshake_failure Unable to negotiate an acceptable set of security parameters given the options available Fatal bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown Various problems with a certificate (corrupted, signatures did not verify, unsupported, revoked, expired, other unspecified issues which render it unacceptable Warning or Fatal, depends on the implementation If fatal, terminate and do not allow resumption with same security parameters (clear all!)

55 Truncation attack TCP TLS TCP FIN An attacker may end connection at any time by sending a TCP FIN Part of the intended information exchange is lost How can Server and Client distinguish this from a transaction that normally completes?

56 Solution: Close Notify Application Data Close Notify Issued by any party Close Notify = Alert (warning level) Informs that no more data will be transmitted A connection that ends abruptly without a Close Notify may be a truncation attack Close Notify A remark: note the weakness of TLS against TCP DOS attacks in general!

57 Conclusive remarks Performance drawbacks: Increased overhead and latency! Mostly for encryption overhead and handshake overhead Computational overhead may kill server performance Up to two orders of magnitude» ref: Transport Layer Security: how much does it really costs? Infocom 99 TLS does NOT protect TCP How to protect non SSL/TLS-aware applications? Tools available to protect a generic TCP connection stunnel = TCP over TLS over TCP» Crazy (tcp tunneled over tcp), but as last resort DOS attacks to TCP remains a significant issue (no protection at all)

58 DTLS Recently specified RFC 4347 Datagram TLS April 2006 TLS over UDP DTLS design goal: Be as most as possible similar to TLS! DTLS vs TLS TLS assumes orderly delivery» DTLS: Sequence number explicitly added in record header TLS assumes reliable delivery» Timeouts added to manage datagram loss TLS may generate large fragments up to 16384B» DTLS includes fragmentation capabilities to fit into single UDP datagram, and recommends Path MTU discovery TLS assumes connection oriented protocol» DTLS connection = (TLS handshake TLS closure Alert)