Winter Term 2011/2012 Chapter 7: Transport Layer Security Protocol Key Questions Application context of TLS? Which security goals shall be achieved? Approaches? 2
Contents Overview Record Protocol Cipher Suites in TLS 1.2 Handshaking Protocols Final Discussion 3 Contents Overview Record Protocol Cipher Suites in TLS 1.2 Handshaking Protocols Final Discussion 4
History Netscape introduced Secure Sockets Layer Protocol (SSL): SSLv1: Never released for use in public applications 1995: SSLv2 (full of flaws) 1996: SSLv3 IETF adopted SSL as an internet standard: 1999: TLS 1.0 as RFC2246 (TLS 1.0 = SSL 3.1) 2006: TLS 1.1 as RFC4346 2008: TLS 1.2 as RFC5246 TLS 1.1 and 1.2 are not widespread (yet) 5 SSL vs. TLS Browsers typically support SSLv3 and TLS 1.0 Major changes in TLS 1.2: Pseudo random function (PRF) is only based on one hash function (SHA-256 recommended) TLS 1.1: PRF is based on MD5 and SHA-1 Cipher Suites containing AES integrated in TLS standard TLS and SSLv3 are not interoperable Usage of different hash based MACs 6
What is TLS? Quote from www.wikipedia.de (accessed 2009-12-20): Das Transport Layer Security (TLS), bzw. sein Vorgängername Secure Sockets Layer (SSL), ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung im Internet. Quote from en.wikipedia.org (accessed 2011-12-16): Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. TLS 1.2: Abstract: [...] The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. 7 Security Goals and Attacks Security goals which may be achieved using TLS: Authenticity Integrity Confidentiality TLS (if properly implemented and utilised) avoids: Network-based eavesdropping (e.g. a sniffer) Spoofing attacks (e.g. simple phishing) Man-in-the-middle-attacks (e.g. sophisticated phishing) Session Hijacking Replay attacks 8
TLS Layers in the Simplified OSI model Application Level Protocols (HTTP, FTP, POP, SMTP, SNMP) Handshake Protocol Change Cipher Spec Protocol Alert Protocol Protocol TLS Record Protocol TCP IP 9 Contents Overview Record Protocol Cipher Suites in TLS 1.2 Handshaking Protocols Final Discussion 10
TLS Sub Protocols: Layer 1 = TLS Record Protocol Receives data from TLS layer 2 Tasks: Fragmentation of data into chunks of at most 214 bytes Compression of each chunk using the current compression function (often no compression is used) Protection (encryption, MAC) of each chunk using the current security parameters TLS record: Record header + protected chunk TLS records are passed down to TCP layer RFCs extending TLS allow UDP, too 11 TLS Record Protocol: Overview Data of TLS Layer 2 m1 Fragmentation with header 1 Compression with header 2 HMAC Encryption with final header 3 1 m2 m3... mt m1 2 2 MAC 3 2 MAC 12
Fragmentation: Data type TLSPlaintext struct { uint8 major; uint8 minor; } ProtocolVersion; (3, 0) = SSLv3 (3, 1) = TLS 1.0 (3, 2) = TLS 1.1 (3, 3) = TLS 1.2 enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; // at most 2^14 opaque fragment[tlsplaintext.length]; // data } TLSPlaintext; 13 Compression: Data type TLSCompressed struct { ContentType type; // same as TLSPlaintext.type ProtocolVersion version;//same as TLSPlaintext.version uint16 length; opaque fragment[tlscompressed.length]; } TLSCompressed; Remarks: fragment is the compression of the whole TLSPlaintext (including its header) Often no compression is used: CompressionMethod.null 14
Record Payload Protection TLSCompressed TLSCiphertext MAC: TLSCiphertext comprises a MAC and encryption Computed over the whole TLSCompressed structure Includes a sequence number to detect missing records and to avoid replay attacks Is based on a hash function as given in the Cipher Suite Encryption: Whole TLSCompressed structure + MAC is encrypted Encryption algorithm as given in the Cipher Suite 15 Security state of the record layer 3 keys for the clients to protect records: client_write_mac_key client_write_key client_write_iv (if a symmetric block cipher is used, e.g. AES) 3 keys for the server to protect records: server_write_mac_key server_write_key server_write_iv (if a symmetric block cipher is used) Write vs. read state: client_write_key is used by server to decrypt (=read) records 16
Key calculation and initial state Keys are calculated using a pseudo random function (PRF) PRF is based on iterated hashing 'Short' input may produce output of arbitrary length Input of the PRF for key calculation: Master secret (which is derived from premaster secret) A random number chosen by the client A random number chosen by the server A fixed string 'key expansion' The key lengths are defined in the cipher suite Initial state: No record protection 17 Contents Overview Record Protocol Cipher Suites in TLS 1.2 Handshaking Protocols Final Discussion 18
TLS Cipher Suites Client and server 'negotiate' a Cipher Suite for their TLS session within the Handshake protocol: Client proposes a sequence of Cipher Suites Server decides, which Cipher Suite is actually used Negotiated parameters are used directly after a ChangeCipherSpec record 19 Structure of TLS Cipher Suites TLS_<ke_alg>_WITH_<cipher>_<mac> ke_alg: Algorithm(s) for key exchange and authentication cipher: Symmetric encryption algorithm used to encrypt the TLS records mac: Hash algorithm to compute HMAC to protect integrity and authenticity of TLS records Client forces server authentication by proposing appropriate Cipher Suite 20
Sample Key Exchange Algorithms (1/2) RSA: Key Exchange via RSA encryption: Implicit authentication based on a server Finished message: Client chooses randomly the PMS Client encrypts PMS using the server's public RSA key Server proves possession of private RSA key Server decrypts encrypted PMS and computes MS Server derives session keys from MS Server's certificate MUST fit: Public key is RSA keyencipherment bit set within its KeyUsage extension 21 Sample Key Exchange Algorithms (2/2) DHE_RSA: Key Exchange via ephemeral Diffie-Hellman (DH): Server chooses randomly his public key dh_ys Client chooses randomly his public key dh_yc PMS is derived from the ephemeral DH parameters Authentication: Server signs his ephemeral DH parameters (dh_p, dh_g, dh_ys) using his private RSA key Server's certificate MUST fit: Server appoints ephemeral DH domain parameters (i.e. prime number dh_p and generator dh_g) Public key is RSA digitalsignature bit set within KeyUsage extension 22
Sample Ciphers and MACs cipher = AES_256_CBC Symmetric block cipher AES is used to encrypt TLS records Key length of AES key is 256 bit Encryption mode is CBC (Cipher Block Chaining) mac = SHA256 Hash function SHA-256 is used to compute HMACs of TLS records 23 Encoding of TLS Cipher Suites Encoding within 2 bytes references: Client and server must be able to recognise the Cipher Suites by means of the 2 bytes Examples from RFC 5246: TLS_RSA_WITH_AES_256_CBC_SHA256 0x003D TLS_RSA_WITH_RC4_128_SHA 0x0005 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0x0033 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 0x006A 24
TLS Cipher Suites from outside RFC 5246 (1/2) RFC 4132 (July 2005): Addition of Camellia Cipher Suites to Transport Layer Security Camellia properties: 128 bit blocks, allows 128, 192, and 256 bit keys Approved e.g. by EU NESSIE-project Examples: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 0x0041 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 0x0045 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0x0084 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0x0088 25 TLS Cipher Suites from outside RFC 5246 (2/2) RFC 4492 (May 2006): Elliptic Curve Cryptography (ECC) Cipher Suites for TLS Examples: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 0xC00A 0xC013 RFC 5289 (August 2008): TLS Elliptic Curve Cipher Suites with SHA-256/384 [ ] Examples: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 0xC023 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 0xC027 26
Default Cipher Suites in Firefox 3.5.6 27 Handshake Firefox 3.5.6 - kunde.comdirect.de 28
Contents Overview Record Protocol Cipher Suites in TLS 1.2 Handshaking Protocols Final Discussion 29 TLS Sub Protocols: Layer 2 TLS Handshaking Protocols: Change Cipher Spec Protocol: Indicates to change from current security state to just negotiated parameters Alert Protocol: 'Throw Exceptions' Handshake Protocol: TLS Protocol: Negotiation of cryptographic parameters Authentication (optional) Receives data from Application Layer and passes it to the TLS Record Layer Wording: Handshaking Protocols vs. Handshake Protocol 30
Change Cipher Spec Protocol (1/2) Aim: Signaling transitions of security parameters ChangeCipherSpec record is sent within Handshake Protocol Sending means that subsequent records will be protected using the newly negotiated write keys by the sending party Receiver sets pending read security state to active read security state A Finished message is sent afterwards to verify the new active security state Type definition: struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; 31 Change Cipher Spec Protocol (2/2) 32
Alert Protocol (1/2) Aim: Signaling severity level and description of alert Alert level (1 byte): Warning (=1) or fatal (=2) Sample alert descriptions (1 byte): bad_record_mac record_overflow bad_certificate unknown_ca decrypt_error = 20 = 22 = 42 = 48 = 51 Type definition: struct { AlertLevel level; // 1 byte AlertDescription description; // 1 byte } Alert; 33 Alert Protocol (2/2) 34
Aims of Handshake Protocol 'Negotiation' of security parameters: Methods for key exchange and authentication Symmetric encryption algorithm and hash algorithm for MACs Further 'negotiation': Compression method, SSL/TLS version for session Resume a session (optional) Authentication (optional): None Only server Both server and client 35 TLS-Handshake: Overview from RFC 5246 Client Server ClientHello ----> <---Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone ----> <---<---> [ChangeCipherSpec] Finished * means optional or situational 36
TLS-Handshake: ClientHello Client Server ClientHello ----> ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone <---Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ----> [ChangeCipherSpec] Finished <---<---> * means optional or situational 37 Fields of Client Hello Message (1/2) ClientHello.client_version: Client-preferred TLS version ClientHello.random: Client-generated 32 byte pseudo random number Bytes 0-3: Current client time encoded as 32 Bit UNIX time Bytes 4-31: 28 byte pseudo random number ClientHello.session_id: Empty: New session or new security parameters requested Non-empty: SessionID to resume 38
Fields of Client Hello Message (2/2) ClientHello.cipher_suites: An ordered list of client-preferred cipher suites Favourite choice first Each cipher suite encoded within 2 bytes ClientHello.compression_methods: An ordered list of client-preferred compression methods Typically null (i.e. no compression used) Extensions: Optional requests for extended functionality Defined outside of TLS 1.0 and TLS 1.1 (e.g. RFC 4366) 39 TLS-Handshake: ServerHello Client Server ClientHello ----> <---Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone ----> <---<---> [ChangeCipherSpec] Finished * means optional or situational 40
Fields of Server Hello Message (1/2) ServerHello.server_version: TLS version used for this TLS session Highest version supported by both client and server Chosen by the server ServerHello.random: Server-generated 32 byte pseudo random number Bytes 0-3: Current server time encoded as 32 Bit UNIX time Bytes 4-31: 28 byte pseudo random number ServerHello.session_id: Session ID of this TLS session as defined by the server 41 Fields of Server Hello Message (2/2) ServerHello.cipher_suite: Single cipher suite selected by the server MUST appear in the ClientHello.cipher_suites array ServerHello.compression_method: Single compression method selected by the server MUST appear in ClientHello.compression_methods Extensions: List of extensions Extension MUST be offered by the client 42
TLS-Handshake: Certificate Client Server ClientHello ----> <---Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone ----> <---<---> [ChangeCipherSpec] Finished * means optional or situational 43 Server Certificate (1/2) Server MUST send this message, if selected cipher suite requires server authentication Client avoids anonymous connection by proposing appropriate cipher suites Server Certificate message comprises certificate chain: First certificate MUST be the server certificate Second certificate MUST be CA certificate issuing server certificate Root CA certificate MAY be omitted (client must verify trusted public key of root CA out of band) 44
Server Certificate (2/2) Certificate type MUST be X.509v3 Server's certificate MUST be in conformance with key exchange method as defined by the cipher suite: RSA: Key Exchange via RSA-encryption DHE_DSS: Key Exchange via ephemeral Diffie-Hellman Server signs his ephemaral DH public key using DSA Server certificate certifies server's public DSA key DHE_RSA: Key Exchange via ephemeral Diffie-Hellman Server signs his ephemaral DH public key using RSA Server certificate certifies server's public RSA key 45 TLS-Handshake: Further Server Messages Client Server ClientHello ----> <---Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone ----> <---<---> [ChangeCipherSpec] Finished * means optional or situational 46
ServerKeyExchange Aim: Typical examples of key exchange methods: Sent by the server, if ServerCertificate message does not contain enough information for key exchange (i.e. PMS) DHE_DSS or DHE_RSA Contents: Ephemeral server DH parameters Server generated signature over server DH parameters ServerKeyExchange method not allowed, if key exchange method is RSA 47 CertificateRequest and ServerHelloDone CertificateRequest: Non-anonymous server requests client authentication Two fields: CertificateRequest.certificate_types : List of certificate types the client may offer (e.g. rsa_sign, dss_sign) CertificateRequest.certificate_authorities : CAs accepted by the server ServerHelloDone: Indicates the end of ServerHello and associated messages Server waits for client response afterwards 48
TLS-Handshake: Further Client Messages Client Server ClientHello ----> ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone <---Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ----> [ChangeCipherSpec] Finished <---<---> * means optional or situational 49 Client Certificate Only sent, if server requests client authentication First message sent by the client after ServerHelloDone Client sends his certificate chain: Client's public key MUST match the requested certificate type One issuer in the chain MUST be present in the server's list If no (appropriate) client certificate is available: Client sends an empty certificate chain Server MAY continue anyway Client's public key is later used for verifying the client signature of the CertificateVerify message 50
Client Key Exchange (1/2) Always sent by the client Aim: Setting of premaster secret (PMS) Key exchange via RSA: Direct transmission of PMS Premaster secret is 48 bytes long: First 2 bytes are the newest TLS version proposed by client Client generates 46 additional random bytes Client encrypts PMS using the server's public key from the ServerCertificate message Inclusion of client TLS version shall prevent rollback attacks 51 Client Key Exchange (2/2) Key exchange via DHE_RSA or DHE_DSS: Premaster secret is computed via Diffie-Hellman Client sends his public value dh_yc to the server within the ClientKeyExchange message PMS is computed as usual: Client makes use of dh_ys and his private client DH key Server makes use of dh_yc and his private server DH key The signature algorithm used for authentication is irrelevant for computing the PMS 52
Certificate Verify Only sent if: Client authentication is required Client's public key within the ClientCertificate has signing capabilities I.e. all client certificate types except static DH certificates (these certificate types are not common) Aim: Client provides credential for client authentication Credential is a client generated signature over all handshake messages Starting with ClientHello Ending before CertificateVerify 53 TLS-Handshake: Final Messages Client Server ClientHello ----> <---Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone ----> <---<---> [ChangeCipherSpec] Finished * means optional or situational 54
Finished (1/2) Always sent immediately after a change cipher spec message Aims: Key exchange was successful Authentication was successful Contents: Pseudo random function invoked with Master Secret A string 'client finished' (client) or 'server finished' (server) Hash of all handshake messages 55 Finished (2/2) Record layer protects Finished message by the newly negotiated algorithms and keys Recipients MUST verify the correctness using the new read security state After a successful Finished message application data may be exchanged 56
Contents Overview Record Protocol Cipher Suites in TLS 1.2 Handshaking Protocols Final Discussion 57