Security Protocols and Infrastructures

Transcription

1 Security Protocols and Infrastructures Dr. Michael Schneider Chapter 8: The Transport Layer Security Protocol (TLS) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 1

2 1 Overview 2 TLS Record Protocol 3 Cipher Suites in TLS Handshaking Protocols 5 The Future: TLS 1.3 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 2

3 1 Overview 2 TLS Record Protocol 3 Cipher Suites in TLS Handshaking Protocols 5 The Future: TLS 1.3 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 3

4 Setup - Who are you? December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 4

5 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 RFC : TLS 1.2 as RFC (?): TLS 1.3 as RFC TLS 1.1 and 1.2 is spreading more and more TLS 1.3 coming soon... December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 5

6 SSL vs. TLS Browsers typically support all TLS versions Browsers are beginning to ban 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 6

7 What is TLS? Quote from (accessed ): Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. TLS and SSL encrypt the segments of network connections at the Application Layer for the Transport Layer, using asymmetric cryptography for key exchange, symmetric encryption for confidentiality, and message authentication codes for message integrity. December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 7

8 What is TLS? Quote from (accessed ): Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. TLS and SSL encrypt the segments of network connections at the Application Layer for the Transport Layer, using asymmetric cryptography for key exchange, symmetric encryption for confidentiality, and message authentication codes for message integrity. TLS 1.2 standard (RFC 5246): 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. December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 7

9 Security Goals and Attacks Security goals which may be achieved using TLS: Authenticity Integrity Confidentiality December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 8

10 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 8

11 TLS Layers in the Simplified OSI model December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 9

12 1 Overview 2 TLS Record Protocol 3 Cipher Suites in TLS Handshaking Protocols 5 The Future: TLS 1.3 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 10

13 TLS Sub Protocols: Protocol Layer 1 = TLS Record Receives data from TLS layer 2 Tasks: Fragmentation of data into chunks of at most 2 14 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 to standardise UDP-based TLS exist, too December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 11

14 TLS Record Protocol: Overview December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 12

15 Fragmentation: Data type TLSPlaintext struct { uint8 major; uint8 minor; } ProtocolVersion; 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; December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 13 (3, 0) = SSLv3 (3, 1) = TLS 1.0 (3, 2) = TLS 1.1 (3, 3) = TLS 1.2

16 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 14

17 Record Payload Protection TLSCompressed TLSCiphertext TLSCiphertext comprises a MAC and encryption MAC: 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 15

18 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) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 16

19 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) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 16

20 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 16

21 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 17

22 1 Overview 2 TLS Record Protocol 3 Cipher Suites in TLS Handshaking Protocols 5 The Future: TLS 1.3 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 18

23 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 19

24 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 Example: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 20

25 Sample Key Exchange Algorithms (1/2) RSA Key Exchange via RSA encryption Client chooses randomly the PMS Client encrypts PMS using the server s public RSA key Implicit authentication based on a server Finished message Server proves possession of private RSA key Server decrypts encrypted PMS and computes MS Server derives session keys from MS December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 21

26 Sample Key Exchange Algorithms (1/2) RSA Key Exchange via RSA encryption Client chooses randomly the PMS Client encrypts PMS using the server s public RSA key Implicit authentication based on a server Finished message 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 21

27 Sample Key Exchange Algorithms (2/2) DHE_RSA: Key Exchange via ephemeral Diffie-Hellman (DH) Server appoints ephemeral DH domain parameters (i.e. prime number dh_p and generator dh_g) 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 22

28 Sample Key Exchange Algorithms (2/2) DHE_RSA: Key Exchange via ephemeral Diffie-Hellman (DH) Server appoints ephemeral DH domain parameters (i.e. prime number dh_p and generator dh_g) 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: Public key is RSA digitalsignature bit set within KeyUsage extension December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 22

29 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 23

30 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 TLS_RSA_WITH_RC4_128_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 0x003D 0x0005 0x0033 0x006A December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 24

31 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 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0x0041 0x0045 0x0084 0x0088 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 25

32 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 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 0xC023 0xC027 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 26

33 Default Cipher Suites in Firefox December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 27

34 Handshake Firefox kunde.comdirect.de December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 28

35 Handshake Firefox 18 - kunde.comdirect.de December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 29

36 1 Overview 2 TLS Record Protocol 3 Cipher Suites in TLS Handshaking Protocols 5 The Future: TLS 1.3 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 30

37 TLS Layers in the Simplified OSI model December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 31

38 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: Negotiation of cryptographic parameters Authentication (optional) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 32

39 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: Negotiation of cryptographic parameters Authentication (optional) TLS Application Data Protocol: Receives data from Application Layer and passes it to the TLS Record Layer December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 32

40 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: Negotiation of cryptographic parameters Authentication (optional) TLS Application Data Protocol: Receives data from Application Layer and passes it to the TLS Record Layer Wording: Handshaking Protocols vs. Handshake Protocol December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 32

41 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 33

42 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; December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 33

43 Change Cipher Spec Protocol (2/2) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 34

44 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 = 20 record_overflow = 22 bad_certificate = 42 unknown_ca = 48 decrypt_error = 51 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 35

45 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 = 20 record_overflow = 22 bad_certificate = 42 unknown_ca = 48 decrypt_error = 51 Type definition: struct { AlertLevel level; // 1 byte AlertDescription description; // 1 byte } Alert; December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 35

46 Alert Protocol (2/2) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 36

47 Aims of Handshake Protocol Negotiation of security parameters: Methods for key exchange and authentication Symmetric encryption algorithm and hash algorithm for MACs December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 37

48 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) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 37

49 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 (1-way TLS) Both server and client (2-way TLS) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 37

50 TLS-Handshake: Overview from RFC 5246 Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 38 * means optional or situational

51 TLS-Handshake: ClientHello Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 39 * means optional or situational

52 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 40

53 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) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 41

54 TLS-Handshake: ServerHello Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 42 * means optional or situational

55 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 43

56 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 44

57 TLS-Handshake: Certificate Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 45 * means optional or situational

58 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) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 46

59 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 47

60 TLS-Handshake: Further Server Messages Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 48 * means optional or situational

61 ServerKeyExchange Aim: Sent by the server, if ServerCertificate message does not contain enough information for key exchange (i.e. PMS) Typical examples of key exchange methods: 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 49

62 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 50

63 TLS-Handshake: Further Client Messages Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 51 * means optional or situational

64 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 52

65 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 53

66 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 54

67 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 55

68 TLS-Handshake: Final Messages Client Server ClientHello > ServerHello Certificate* ServerKeyExchange* CertificateRequest* < ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished > [ChangeCipherSpec] < Finished Application Data < > Application Data December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 56 * means optional or situational

69 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 57

70 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 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 58

71 1 Overview 2 TLS Record Protocol 3 Cipher Suites in TLS Handshaking Protocols 5 The Future: TLS 1.3 December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 59

72 Goals of TLS 1.3 Remove outdated cryptographic algorithms Enhance performance learn from attacks against TLS 1.0-TLS 1.2 (e.g. BEAST, Crime, Lucky Thirteen, Triple Handshake) Replace MAC-then-Encrypt December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 60

73 Goals of TLS 1.3 use authenticated encryption (AEAD) only AES-GCM, ChaCha20-Poly1305 where already available in TLS 1.2 Remove TLS Compression Remove RSA key exchange (and with that: enforce forward secrecy) for RSA signatures: replace PKCS#1 1.5 padding by PSS (Probabilistic Signature Scheme) Remove one round in TLS handshake (enable faster message exchange) Allow for zero-round-trip time (0-RTT) if previous connection was already established Change PMS computation (to tackle Triple-Handshake attack) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 61

74 Status of the RFC draft December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 62

75 TLS 1.3 Overview December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 63

76 Software Supporting TLS 1.3 Chrome (experimental) Firefox (experimental) Opera (experimental) Nginx... December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 64

77 Conclusion on TLS 1.3 Great security improvements Performance enhancements Potential downgrade issues (backwards compatibility) New potential attack vectors by 0-RTT (no forward secreccy,...) December 4, 2017 h_da WS2017/18 Dr. Michael Schneider 65