SSL, TLS and DTLS

1. Dina Odeh dodeh@cisco.com Cisco TAC Engineer SSL, TLS and DTLS

2. Why VPN !!

3. We all use VPN to achieve both : • Privacy • Security • The security provided for VPN is achieved by the implementation of cryptographic protocols such as: • IPsec • SSL • TLS • DTLS • So now we know what are these protocols, these are the one used to provide a secure tunnel and means of data transmission for the purposes of providing remote users and sites access to your internal resources. • Before these protocols can establish a secure communications tunnel (VPN) between two endpoints, they generate, exchange, and use keys as a means to authenticate/encrypt the information used to create a secure tunnel that is sent between both parties. Each protocol goes through specific stages when establishing a secure tunnel. Depending on the stage they are at in their negotiations, either a symmetric or asymmetric encryption keys is used. • In these slides we will focus on the last three protocols, but first we will have a quick recap about these keys.

4. So, what are symmetric and asymmetric key algorithms? Well, without noticing, you’ve probably come across them, heard of them, and no doubt have used them without even knowing (when shopping online, for example). Symmetric and Asymmetric Keys

5. Decrypt Encrypt KEY KEY $1000 $!@#lQ $1000 Symmetric key algorithms Same Not necessarily The same

6. During their operation, symmetric key algorithms generate and use a single key for the purposes of encrypting and decrypting data. Examples of symmetric key algorithms include Digital Encryption Standard (DES) , Triple DES (3DES) , and Advanced Encryption Standard (AES) . The downside with using a single key for both encryption and decryption is just that: If attackers gain access to the key used for encrypting sensitive data, they are automatically able to decrypt and read it. Some argue that symmetric key algorithms are subject to brute-force attacks (given enough computing power), whereby attackers attempt to “guess” the key by literally trying number after number against an encrypted piece of data. However, efforts have been made to overcome this problem, mainly by the introduction of a larger key size. • Examples of symmetric algorithms and their key sizes include the following: • DES uses a key size of 56 bits. • 3DES uses a key size of 168 bits. • AES offers 128, 192, 256 key sizes.

7. Symmetric encryption algorithms are prone to a specific problem: the process of key exchange. As mentioned earlier, for two parties to be able to encrypt and decrypt data they must both be in possession of the same key. However, this means the encryption/decryption key must be exchanged somehow, which leaves it open to potential attackers if, for example, the key is exchanged in an email. Therefore, asymmetric encryption protocols are commonly used to set up a secure communications path for the purpose of exchanging the symmetric key.

8. Encrypt Asymmetric Algorithms Decryption Key Encryption Key Decrypt $1000 %3f7&4 $1000 The encryption and decryption keys are different

9. Instead of using one single key to perform the encryption/decryption operation, asymmetric • key algorithms use a key pair, one key for encryption and one key for decryption. • Because of a mathematical relationship of the two keys generated, a piece of information • or data that has been encrypted can be decrypted only by the key that belongs • to the corresponding key pair of the encryption key used. You might have heard of the • terms public and private key before. These terms refer to the keys used by asymmetric • key algorithms. Usually, a public key is distributed to people who expect to receive • the encrypted data (commonly using digital certificates), and a private key is kept and • known only to the person encrypting the data. Public/private key pairs are also easier to • distribute than keys used with symmetric algorithms. For example, if you were to send • the key used by a symmetric key algorithm to decrypt some information to a host across • the Internet, an attacker could likely intercept this key and the messages sent between • the source and destination and could then freely decrypt and read them. • Examples of asymmetric key algorithms include the following: • Rivest, Shamir, and Adleman (RSA) • Diffie-Hellman (DH)

10. When working with VPNs, you will often see asymmetric key algorithms used (for example, DH used to encrypt and securely exchange symmetric keys). The sending and receiving hosts at either end of the VPN exchange symmetric keys to encrypt and decrypt any data sent. Their use is popular because of the simplicity of symmetric encryption protocols in terms of mathematics and the ability to run them within hardware at a very fast rate. However, asymmetric encryption algorithms often use larger key sizes and more-sophisticated and processor-intensive mathematical functions such as discrete logarithms or factoring large prime numbers, so their use is limited mainly to key exchange or for authentication purposes (RSA tokens).

11. SSL, TLS and DTLS

12. SSL and TLS Versions

13. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network.[1] They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating,[2] and to negotiate a symmetric session key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication.[clarification needed] Several versions of the protocols are in widespread use in applications such as web browsing, email, Internet faxing, instant messaging, and voice-over-IP (VoIP). An important property in this context is forward secrecy, so the short-term session key cannot be derived from the long-term asymmetric secret key.[3] In the Internet Protocol Suite, TLS and SSL encrypt the data of network connections in the application layer. In OSI model equivalences, TLS/SSL is initialized at layer 5 (session layer) and works at layer 6 (the presentation layer).[citation needed] The session layer has a handshake using an asymmetric cipher in order to establish cipher settings and a shared key for that session; then the presentation layer encrypts the rest of the communication using a symmetric cipher and that session key. In both models, TLS and SSL work on behalf of the underlying transport layer, whose segments carry encrypted data.

14. History

15. SSL v1.0 • Version 1.0 was never publicly released because of serious security flaws in the protocol SSL v2.0 • not recommended for use in production environments • contained a number of security flaws which ultimately led to the design of SSL version 3.0 • SSL version 2.0 [SSL2] deficiencies include the following: • Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151]. • Handshake messages are not protected. This permits a man-in-the-middle to trick the client into picking a weaker cipher suite than it would normally choose. • Message integrity and message encryption use the same key, which is a problem if the client and server negotiate a weak encryption algorithm. • Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session.

16. As per the RFC, Because of the deficiencies noted, we need to change to TLS so: • TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-HELLO message format. Clients MUST NOT send any ClientHello message that specifies a protocol version less than { 0x03, 0x00 }. As previously stated by the definitions of all previous versions of TLS, the client SHOULD specify the highest protocol version it supports. • TLS servers MAY continue to accept ClientHello messages in the version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2], Appendix E.2. Note that this does not contradict the prohibition against actually negotiating the use of SSL 2.0. • TLS servers MUST NOT reply with an SSL 2.0 SERVER-HELLO with a protocol version that is less than { 0x03, 0x00 } and instead MUST abort the connection, i.e., when the highest protocol version offered by the client is { 0x02, 0x00 }, the TLS connection will be refused. RFC 6176 https://tools.ietf.org/html/rfc6176

17. SSL v3.0 • SSL version 3.0, released in 1996, represented a complete redesign of the protocol. • As per RFC 7569, SSL v3 is now deprecated. • The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. • It is now recommended as per the RFCs not to use SSL v3 and to use TLS instead. The best is to use the TLS v1.2 Refer to the following RFCs to know more about SSL v3 and to know why it is not secure now: RFC 7568 https://tools.ietf.org/html/rfc7568 RFC 6101 http://tools.ietf.org/html/rfc6101#section-1

18. TLS v1.0 • TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0 • The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). • The TLS Record Protocol is used for encapsulation of various higher level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security RFC 2246 https://tools.ietf.org/html/rfc2246

19. TLS v1.1 • TLS 1.1 was defined in RFC 4346 in April 2006. • This document is a revision of the TLS 1.0 [TLS1.0] protocol, and contains some small security improvements, clarifications, and editorial improvements. The major changes are: • The implicit Initialization Vector (IV) is replaced with an explicit IV to protect against CBC attacks [CBCATT]. • Handling of padding errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks. • IANA registries are defined for protocol parameters. • Premature closes no longer cause a session to be nonresumable. • Additional informational notes were added for various new attacks on TLS. RFC 4346 http://tools.ietf.org/html/rfc4346

20. TLS v1.2 • TLS 1.2 was defined in RFC 5246 in August 2008. • The major changes between this version and the TLS v1.1 are: • The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256. • The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash. Signed elements now include a field that explicitly specifies the hash algorithm used. • Substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept. Note that this also relaxes some of the constraints on signature and hash algorithms from previous versions of TLS. • Addition of support for authenticated encryption with additional data modes. • TLS Extensions definition and AES Cipher Suites were merged in from external [TLSEXT] and [TLSAES].

21. Tighter checking of EncryptedPreMasterSecret version numbers. • Tightened up a number of requirements. • Verify_data length now depends on the cipher suite (default is still 12). • Cleaned up description of Bleichenbacher/Klima attack defenses. • Alerts MUST now be sent in many cases. • After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list. • TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite. • Added HMAC-SHA256 cipher suites. • Removed IDEA and DES cipher suites. They are now deprecated and will be documented in a separate document.

22. Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD, with sending it a SHOULD NOT. Support will probably become a SHOULD NOT in the future. • Added limited "fall-through" to the presentation language to allow multiple case arms to have the same encoding. • Added an Implementation Pitfalls sections • The usual clarifications and editorial work. RFC 5246 https://tools.ietf.org/html/rfc5246

23. TLS v1.3 • As of July 2015, TLS 1.3 is a working draft, and details are provisional and incomplete. It is based on the earlier TLS 1.2 specification. Major differences from TLS 1.2 include: • Integration of HKDF and the semi-ephemeral DH proposal • Replacement of resumption with PSK and tickets • Relegation of ClientKeyShare to an appendix • Support for 1-RTT handshakes and initial support for 0-RTT • Dropped support for many insecure or obsolete features including, compression, renegotiation, non-AEAD ciphers, static RSA and DH key exchange, custom DHE groups, point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers • Prohibition of SSL or RC4 negotiation for backwards compatibility • Integrated usage of session hash • The record layer version number has been frozen and deprecated for improved backwards compatibility • Movement of some security related algorithm details from an appendix to the specification

24. SSL and TLS Handshake

25. SSL Record Overview The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records.

26. SSL Record Overview • There are four record types in SSL: • Handshake (22, 0x16) • Change Cipher Spec (20, 0x14) • Alert (21, 0x15) • Application Data (23, 0x17) The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records.

27. SSL Record Overview • There are four record types in SSL: • Handshake (22, 0x16) • Change Cipher Spec (20, 0x14) • Alert (21, 0x15) • Application Data (23, 0x17) The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records. Handshake Records Handshake records contain a set of messages that are used in order to handshake. These are the messages and their values: Hello Request (0, 0x00) Client Hello (1, 0x01) Server Hello (2, 0x02) Certificate (11, 0x0B) Server Key Exchange (12, 0x0C) Certificate Request (13, 0x0D) Server Hello Done (14, 0x0E) Certificate Verify (15, 0x0F) Client Key Exchange (16, 0x10) Finished (20, 0x14)

28. SSL Record Overview • There are four record types in SSL: • Handshake (22, 0x16) • Change Cipher Spec (20, 0x14) • Alert (21, 0x15) • Application Data (23, 0x17) The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records. Change Cipher Spec Records CCS records are used in order to indicate a change in cryptographic ciphers. Immediately after the CCS record, all data is encrypted with the new cipher. CCS records might or might not be encrypted; in a simple connection with a single handshake, the CCS record is not encrypted.

29. SSL Record Overview • There are four record types in SSL: • Handshake (22, 0x16) • Change Cipher Spec (20, 0x14) • Alert (21, 0x15) • Application Data (23, 0x17) The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records. Alert Records Alert records are used in order to indicate to the peer that a condition has occured. Some alerts are warnings, while others are fatal and cause the connection to fail. Alerts might or might not be encrypted, and might occur during a handshake or during data transfer. There are two types of alerts: Closure Alerts. Error Alerts

30. SSL Record Overview • There are four record types in SSL: • Handshake (22, 0x16) • Change Cipher Spec (20, 0x14) • Alert (21, 0x15) • Application Data (23, 0x17) The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records. Application Data Record These records contain the actual application data. These messages are carried by the record layer and are fragmented, compressed, and encrypted, based on the current connection state.

31. SSL Record Overview Version This field identifies the major and minor version of TLS for the contained message. The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records.

32. SSL Record Overview The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records. Length The length of Protocol message(s), MAC and Padding, not to exceed 214 bytes (16 KiB).

33. SSL Record Overview The basic unit of data in SSL is a record. Each record consists of a five-byte record header, followed by data. This is the general format of all TLS records. Encapsulated Protocol Message Carries the messages or application data sent between client and server during a conversation. After the authentication, encryption, and hash parameters have been negotiated, this field may be encrypted.

34. Lets take the following Wire shark for a client hello packet and study the SSL record

35. Lets take the following Wire shark for a client hello packet and study the SSL record Here is the SSL Record

36. There are four record types in SSL: • Handshake (22, 0x16) • Change Cipher Spec (20, 0x14) • Alert (21, 0x15) • Application Data (23, 0x17) Lets take the following Wire shark for a client hello packet and study the SSL record Content Field is Handshake (( 22 ))

37. Lets take the following Wire shark for a client hello packet and study the SSL record Version This field identifies the major and minor version of TLS for the contained message. Vesrion Field is TLS 1.0

38. Lets take the following Wire shark for a client hello packet and study the SSL record Length The length of Protocol message(s), MAC and Padding, not to exceed 214 bytes (16 KiB). Length Field is 92

39. Lets take the following Wire shark for a client hello packet and study the SSL record Encapsulated Protocol Message Carries the messages or application data sent between client and server during a conversation. After the authentication, encryption, and hash parameters have been negotiated, this field may be encrypted. Encapsulated Protocol Messages here present the content of the handshake protocol, And especially the client hello message.

40. So now lets start with the 4 record types one by one • There are four record types in SSL: • Handshake (22, 0x16) • Change Cipher Spec (20, 0x14) • Alert (21, 0x15) • Application Data (23, 0x17)

41. Handshake Protocol: Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record or the encryption mode of the session is modified by another record. See the following Handshake Protocol Record:

42. Handshake Protocol: Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record or the encryption mode of the session is modified by another record. See the following Handshake Protocol Record: For sure the type here is 22 because we agree that Handshake protocols take number 22

43. Handshake Protocol: Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record or the encryption mode of the session is modified by another record. See the following Handshake Protocol Record: As we can see here, the encapsulated protocol Message here represent The handshake protocol messages. We will go for each one of them one by one.

44. Handshake Protocol: Message type This field identifies the Handshake message type. Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record or the encryption mode of the session is modified by another record. See the following Handshake Protocol Record:

45. Handshake Protocol: Message type This field identifies the Handshake message type. Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record or the encryption mode of the session is modified by another record. See the following Handshake Protocol Record: • Hello Request • When this message will be sent: • The HelloRequest message MAY be sent by the server at any time. • Meaning of this message: • HelloRequest is a simple notification that the client should begin the negotiation process anew. In response, the client should send a ClientHello message when convenient. This message is not intended to establish which side is the client or server but merely to initiate a new negotiation. Servers SHOULD NOT send a HelloRequest immediately upon the client's initial connection. It is the client's job to send a ClientHello at that time.

46. Handshake Protocol: Message type This field identifies the Handshake message type. Most messages exchanged during the setup of the TLS session are based on this record, unless an error or warning occurs and needs to be signaled by an Alert protocol record or the encryption mode of the session is modified by another record. See the following Handshake Protocol Record: • Client Hello Message • When this message will be sent: • When a client first connects to a server, it is required to send the ClientHello as its first message. The client can also send a clientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection. • The Client Hello sends these attributes to the server:  • Protocol Version: The version of the SSL protocol by which the client wishes to communicate during this session. • Session ID: The ID of a session the client wishes to use for this connection. In the first Client Hello of the exchange, the session ID is empty. • Cipher Suite: This is passed from the client to the server in the Client Hello message. It contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (first choice first). Each cipher suite defines both a key exchange algorithm and a cipher spec. The server selects a cipher suite or, if no acceptable choices are presented, returns a handshake failure alert and closes the connection. • Compression Method: Includes a list of compression algorithms supported by the client. If the server does not support any method sent by the client, the connection fails. The compression method can also be null. 

47. Example This is a Client Hello Packet

48. Example Protocol Version: The version of the SSL protocol by which the client wishes to communicate during this session Here Client want to use TLS 1.0

49. Example Session ID: The ID of a session the client wishes to use for this connection. In the first Client Hello of the exchange, the session ID is empty. Here the session ID is empty, therefore the length is zero.

50. Example Cipher Suite: This is passed from the client to the server in the Client Hello message. It contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (first choice first). Each cipher suite defines both a key exchange algorithm and a cipher spec. The server selects a cipher suite or, if no acceptable choices are presented, returns a handshake failure alert and closes the connection. Here we can see what ciphers this client support and he send it to the server.