Intro to SSL, TLS and DTLS

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialIntro_to_IPSec 1

SSL, TLS and DTLSDina Odeh

[email protected]

Cisco TAC Engineer


Why VPN !!


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.


Symmetric and Asymmetric Keys

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 key algorithms

$1000$1000 $!@#lQ$!@#lQ $1000$1000DecryptDecryptEncryptEncrypt

KEY KEY

Same

Not necessarilyThe same

User

kef el encryption wel decryption algorithms are different


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.


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.


Encryption Key

DecryptDecrypt

Decryption Key

$1000$1000 %3f7&4%3f7&4 $1000$1000EncryptEncrypt

Asymmetric Algorithms

The encryption and decryption keys are different


Instead of using one single key to perform the encryption/decryption operation, asymmetrickey 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 informationor data that has been encrypted can be decrypted only by the key that belongsto the corresponding key pair of the encryption key used. You might have heard of theterms public and private key before. These terms refer to the keys used by asymmetrickey algorithms. Usually, a public key is distributed to people who expect to receivethe encrypted data (commonly using digital certificates), and a private key is kept andknown only to the person encrypting the data. Public/private key pairs are also easier todistribute than keys used with symmetric algorithms. For example, if you were to sendthe key used by a symmetric key algorithm to decrypt some information to a host acrossthe Internet, an attacker could likely intercept this key and the messages sent betweenthe 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)


When working with VPNs, you will often see asymmetric key algorithms used (forexample, 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).


SSL, TLS and DTLS


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.


Protocol Year RFC

SSL 1.0 N/A ---SSL 2.0 1995 6176SSL 3.0 1996 6101TLS 1.0 1999 2246TLS 1.1 2006 4346TLS 1.2 2008 5246TLS 1.3 TBD ---


SSL v1.0

SSL v2.0

Version 1.0 was never publicly released because of serious security flaws in the protocol

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.


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.

https://tools.ietf.org/html/rfc6176

RFC 6176


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

SSL v3.0

Refer to the following RFCs to know more about SSL v3 and to know why it is not secure now:

RFC 7568

RFC 6101


http://tools.ietf.org/html/rfc6101#section-1


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 2246https://tools.ietf.org/html/rfc2246


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


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].


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.


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



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 proposalReplacement of resumption with PSK and ticketsRelegation of ClientKeyShare to an appendixSupport for 1-RTT handshakes and initial support for 0-RTTDropped 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 ciphersProhibition of SSL or RC4 negotiation for backwards compatibilityIntegrated usage of session hashThe record layer version number has been frozen and deprecated for improved backwards compatibilityMovement of some security related algorithm details from an appendix to the specification


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.




There are four record types in SSL:

Handshake (22, 0x16)

Change Cipher Spec (20, 0x14)

Alert (21, 0x15)

Application Data (23, 0x17)







Alert (21, 0x15)

Application Data (23, 0x17)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)







Alert (21, 0x15)


Change Cipher Spec RecordsCCS 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.







Alert (21, 0x15)


Alert RecordsAlert 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







Alert (21, 0x15)


Application Data RecordThese 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.




Version

This field identifies the major and minor version of TLS for the contained message.




LengthThe length of Protocol message(s), MAC and Padding, not to exceed 214 bytes (16 KiB).




Encapsulated Protocol MessageCarries 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.


Here is the SSL Record


Content Field is Handshake (( 22 ))




Alert (21, 0x15)



Vesrion Field is TLS 1.0

Version

This field identifies the major and minor version of TLS for the contained message.


Length Field is 92

LengthThe length of Protocol message(s), MAC and Padding, not to exceed 214 bytes (16 KiB).


Encapsulated Protocol Messages here present the content of the handshake protocol, And especially the client hello message.

Encapsulated Protocol MessageCarries 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.





Alert (21, 0x15)



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



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.



Message typeThis field identifies the Handshake message type.




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.




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.


This is a Client Hello Packet


Protocol Version: The version of the SSL protocol by which the client wishes to communicate during this

sessionHere Client want to use TLS 1.0


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.


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.


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.

Here the compression method is null.




Server Hello Message

•When this message will be sent:

The server will send this message in response to a ClientHello message when it was able to find an acceptable set of algorithms. If it cannot find such a match, it will respond with a handshake failure alert.

•The server sends back these attributes to the client: Protocol Version: The chosen version of the SSL protocol that the client supports.Session ID: This is the identity of the session that corresponds to this connection. If the session ID sent by the client in the Client Hello is not empty, the server looks in the session cache for a match. If a match is found and the server is willing to establish the new connection using the specified session state, the server responds with the same value that was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the finished messages. Otherwise, this field contains a different value that identifies the new session. The server might return an empty session_id in order to indicate that the session will not be cached, and therefore cannot be resumed.Cipher Suite: As selected by the server from the list that was sent from the client. Compression Method: As selected by the server from the list that was sent from the client.




Certificate Message


The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication. This message will always immediately follow the ServerHello message.

• Meaning of this message:

This message conveys the server's certificate chain to the client. The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions.




Server Hello Done Message


The ServerHelloDone message is sent by the server to indicate the end of the ServerHello and associated messages. After sending this message, the server will wait for a client response.


This message means that the server is done sending messages to support the key exchange, and the client can proceed with its phase of the key exchange.

Upon receipt of the ServerHelloDone message, the client SHOULD verify that the server provided a valid certificate, if required, and check that the server hello parameters are acceptable.


Here in this packet, we can see the three messages:

Server HelloCertificateServer Hello Done


Protocol Version is TLS 1.0Session ID Value

Cipher chooses by the server

Since already the sent compression method from the client was null. Server send null also.

Server Hello Message


Server Here had only one certificate and he send it to the client

Certificate Message


Server Hello Done Message




Client Key Exchange Message


This message is always sent by the client. It MUST immediately follow the client certificate message, if it is sent. Otherwise, it MUST be the first message sent by the client after it receives the ServerHelloDone message.


With this message, the premaster secret is set, either by direct transmission of the RSA-encrypted secret or by the transmission of Diffie-Hellman parameters that will allow each side to agree upon the same premaster secret.

When the client is using an ephemeral Diffie-Hellman exponent, then this message contains the client's Diffie-Hellman public value. If the client is sending a certificate containing a static DH exponent (i.e., it is doing fixed_dh client authentication), then this message MUST be sent but MUST be empty.




Server Key Exchange Message

• When this message will be sent:

This message will be sent immediately after the server Certificate message (or the ServerHello message, if this is an anonymous negotiation).

The ServerKeyExchange message is sent by the server only when the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods:

DHE_DSS DHE_RSA DH_anon

It is not legal to send the ServerKeyExchange message for the following key exchange methods:

RSA DH_DSS DH_RSA.




Certificate Request Message


A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will immediately follow the ServerKeyExchange message (if it is sent; otherwise, this message follows the server's Certificate message).




Certificate Verify Message

• When this message will be sent:

This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters). When sent, it MUST immediately follow the client key exchange message.




Finished Message


A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. It is essential that a change cipher spec message be received between the other handshake messages and the Finished message.


The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets. Recipients of Finished messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.



Handshake message data length

This is a 3-byte field indicating the length of the handshake data, not including the header. Note that multiple Handshake messages may be combined within one record.





Alert (21, 0x15)



The Change Cipher Spec message is sent by the client, and the client copies the pending Cipher Spec (the new one) into the current Cipher Spec (the one that was previously used). Change Cipher Spec protocol exists in order to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) Cipher Spec. The message is sent by both the client and server in order to notify the receiving party that subsequent records are protected under the most recently negotiated Cipher Spec and keys. Reception of this message causes the receiver to copy the "read pending" state into the "read current" state. The client sends a Change Cipher Spec message following handshake key exchange and Certificate Verify messages (if any), and the server sends one after it successfully processes the key exchange message it received from the client. When a previous session is resumed, the Change Cipher Spec message is sent after the Hello messages.

The Change Cipher Spec Protocol Record Look Like:

This value always equal one





Alert (21, 0x15)



One of the content types supported by the TLS record layer is the alert type. Alert messages convey the severity of the message (warning or fatal) and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.

The Alert Protocol Record Look Like:


One of the content types supported by the TLS record layer is the alert type. Alert messages convey the severity of the message (warning or fatal) and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.

The Alert Protocol Record Look Like:

Level Field:

Please refer to this link to see all description possible values:https://en.wikipedia.org/wiki/Transport_Layer_Security#Alert_protocol





Alert (21, 0x15)



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.

The Application Data Protocol Record Look Like:


A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:

1- Negotiation phase:

•A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.•The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports version 1.1 and the server supports version 1.2, version 1.1 should be selected; 1.0 should not be selected.•The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).•The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE and DH_anon ciphersuites.•The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.•The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.•The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.


2- The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.•Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.•The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.

3- Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."•The server sends its authenticated and encrypted Finished message.•The client performs the same decryption and verification.

4- Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.

https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

You can refer to this link, It is very useful:


https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers


TLS [TLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent connection-oriented channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the transport layer. However, TLS must run over a reliable transport channel -- typically TCP [TCP]. It therefore cannot be used to secure unreliable datagram traffic.

However, over the past few years an increasing number of application layer protocols have been designed that use UDP transport. In particular protocols such as the Session Initiation Protocol (SIP)[SIP] and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable). Currently, designers of these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC2401]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. SIP, for instance, uses a subset of S/MIME to secure its traffic. Unfortunately, although application layer security protocols generally provide superior security properties (e.g., end-to-end security in the case of S/MIME), they typicallyrequires a large amount of effort to design -- in contrast to the relatively small amount of effort required to run the protocol over TLS.

In many cases, the most desirable way to secure client/server applications would be to use TLS; however, the requirement for datagram semantics automatically prohibits use of TLS. Thus, adatagram-compatible variant of TLS would be very desirable. This memo describes such a protocol: Datagram Transport Layer Security (DTLS). DTLS is deliberately designed to be as similar to TLS aspossible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse.


Differences from TLS

DTLS is intentionally very similar to TLS. Therefore, instead of presenting DTLS as a new protocol, we present it as a series of deltas from TLS 1.1. Where we do not explicitly call out differences, DTLS is the same as in .

The DTLS Handshake Protocol

DTLS uses all of the same handshake messages and flows as TLS, with three principal changes:

1. A stateless cookie exchange has been added to prevent denial of service attacks.

2. Modifications to the handshake header to handle message loss, reordering, and fragmentation.

3. Retransmission timers to handle message loss.

With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.1.

For more, please refer to: http://tools.ietf.org/html/rfc4347#section-4.2


ASA and SSL/TLS


To specify the SSL/TLS protocol version that the ASA uses when acting as a client, use the ssl client-version command in global configuration mode. To revert to the default, use the no form of this command.

Command Format :

ssl client-version [ any | sslv3-only | tlsv1-only | sslv3 | tlsv1 | tlsv1.1 | tlsv1.2 ]

Protocol Description

any Transmits SSLv3 client hellos and negotiates SSLv3 (or greater).

sslv3 Transmits SSLv3 client hellos and negotiates SSLv3 (or greater).

sslv3-only Transmits SSLv3 client hellos and negotiates SSLv3 (or greater).Note This option has been deprecated as of Version 9.3(2).

tlsv1 Transmits TLSv1 client hellos and negotiates TLSv1 (or greater).

tlsv1.1 Transmits TLSv1.1 client hellos and negotiates TLSv1.1 (or greater).


tlsv1-only Transmits TLSv1 client hellos and negotiates TLSv1 (or greater).Note This option has been deprecated as of Version 9.3(2).



Command Format :










These Keyword has been deprecated on 9.3(2) version. So when you try to add one of them you willsee the warning “WARNING: SSLv3 is deprecated. Use of TLSv1 or greater is recommended.”.

These keyword has been removed at all on 9.4(1) version and later.



Command Format :










Starting 9.3(2) we now support TLS version 1.2 for secure message transmission for ASDM, Clientless SSVPN, and AnyConnect VPN.



Command Format :










Has been deprecated on 9.3(2) version and is no longer seen at 9.4(1) and later. Reason: Same as tlsv1


To set the minimum protocol version for which the ASA will negotiate an SSL/TLS connection, use the ssl server-version command in global configuration mode. To revert to the default, any, use the no form of this command.

Command Format :

ssl server-version [ any | sslv3-only | tlsv1-only | sslv3 | tlsv1 | tlsv1.1 | tlsv1.2 ]


any Accepts SSLv2 client hellos and negotiates the highest common version

sslv3 Accepts SSLv2 client hellos and negotiates SSLv3 (or greater).

sslv3-only Accepts SSLv2 client hellos and negotiates SSLv3 (or greater).Note This option has been deprecated as of Version 9.3(2).

tlsv1 Accepts SSLv2 client hellos and negotiates TLSv1 (or greater).

tlsv1.1 Accepts SSLv2 client hellos and negotiates TLSv1.1 (or greater).


tlsv1-only Accepts SSLv2 client hellos and negotiates TLSv1 (or greater).Note This option has been deprecated as of Version 9.3(2).



Command Format :










These Keyword has been deprecated on 9.3(2) version. So when you try to add one of them you willsee the warning “WARNING: SSLv3 is deprecated. Use of TLSv1 or greater is recommended.”.

These keyword has been removed at all on 9.4(1) version and later.



Command Format :










Starting 9.3(2) we now support TLS version 1.2 for secure message transmission for ASDM, Clientless SSVPN, and AnyConnect VPN.



Command Format :










Has been deprecated on 9.3(2) version and is no longer seen at 9.4(1) and later. Reason: Same as tlsv1


To specify the encryption algorithms for the SSL, DTLS, and TLS protocols, use the ssl encryption command in global configuration mode. To restore the default, which is the complete set of encryption algorithms, use the no form of this command.Command Format :

ssl encryption [ 3des-sha1 ] [ aes128-sha1 ] [ aes256-sha1 ] [ des-sha1 ] [null-sha1] [ rc4-md5 ] [rc4-sha1] [ dhe-aes256-sha1 ] [ dhe-aes128-sha1 ]

Algorithm Description

3des-sha1 Specifies triple DES 168-bit encryption with Secure Hash Algorithm 1 (FIPS-compliant).

aes128-sha1 Specifies triple AES 128-bit encryption with Secure Hash Algorithm 1 (FIPS-compliant).


dhe-aes128-sha1 Specifies AES 128-bit encryption cipher suites for Transport Layer Security (TLS) (FIPS-compliant).


des-sha1 Specifies DES 56-bit encryption with Secure Hash Algorithm 1.

null-sha1 Specifies null encryption with Secure Hash Algorithm 1. This setting enforces message integrity without confidentiality.

rc4-md5 Specifies RC4 128-bit encryption with an MD5 hash function.

rc4-sha1 Specifies RC4 128-bit encryption with Secure Hash Algorithm 1.














We have to know that this command is removed on 9.3(2) version and the

“ssl cipher” command take it’s place.














These two algorithms were added on 9.1(2) version.














By default, the SSL encryption list on the ASA contains these algorithms in the following order:

1. RC4-SHA12. AES128-SHA1 (FIPS-compliant)3. AES256-SHA1 (FIPS-compliant)

4. 3DES-SHA1 (FIPS-compliant)5. DHE-AES256-SHA1 (FIPS-compliant)6. DHE-AES128-SHA1 (FIPS-compliant)


To specify the encryption algorithms for the SSL, DTLS, and TLS protocols, use the ssl cipher command in global configuration mode. To restore the default, which is the complete set of encryption algorithms, use the no form of this command.Command Format :

ssl cipher version [ level | custom “ string ”]

custom string Allows full control of the cipher suite using OpenSSL cipher definition strings.

level Specifies the strength of the cipher and indicates the minimum level of ciphers that are supported. Valid values in increasing order of strength are:

all —Includes all ciphers, including NULL-SHA. low —Includes all ciphers except NULL-SHA.

medium —Includes all ciphers except NULL-SHA, DES-CBC-SHA, and RC4-MD5.

fips —Includes all FIPS-compliant ciphers (excludes NULL-SHA, DES-CBC-SHA, RC4-MD5, RC4-SHA, and DES-CBC3-SHA.

high (applies only to TLSv1.2)—Includes only AES-256 with SHA-2 ciphers.

version Specifies the SSL, DTLS, or TLS protocol version. Supported versions include:

default —The set of ciphers for outbound connections. dtlsv1 —The ciphers for DTLSv1 inbound connections.

sslv3 —The ciphers for SSLv3 inbound connections. tlsv1 —The ciphers for TLSv1 inbound connections.

tlsv1.1 —The ciphers for TLSv1.1 inbound connections. tlsv1.2 —The ciphers for TLSv1.2 inbound connections.














This command replaced the ssl encryption command starting with ASA

Version 9.3(2).

Has been removed on ASA 9.4(1)














The ASA specifies the order of priority for supported ciphers as:

Ciphers supported by TLSv1.2 (1-9)1. DHE-RSA-AES256-SHA256

2. AES256-SHA2563. DHE-RSA-AES128-SHA256

4. AES128-SHA2565. DHE-RSA-AES256-SHA

6. AES256-SHA7. DHE-RSA-AES128-SHA

8. AES128-SHA9. DES-CBC3-SHA

Ciphers not supported by TLSv1.1 or TLSv1.2 (10-13)10. RC4-SHA11. RC4-MD5

12. DES-CBC-SHA13. NULL-SHA














When you try to change the value for this command you will see a summary after typing Enter with the used and skipped ciphers for this protocol at this level, as an example:

In the next slide, you can see a table summarize the used and skipped ciphers for each protocol for all levels.


Means that ciphers is skipped because it’s not supported the protocol.

Means that ciphers is skipped because it’s not supported the level.

Means that ciphers will be used for this protocol and that this level.


Using the “show ssl cipher” command is the best way to check what is the used ciphers for each protocol at the level configured on your device. For example if you have these config:

ssl server-version tlsv1ssl client-version tlsv1ssl cipher default mediumssl cipher sslv3 allssl cipher tlsv1 allssl cipher tlsv1.1 allssl cipher tlsv1.2 allssl cipher dtlsv1 mediumssl dh-group group2ssl certificate-authentication fca-timeout 2

The output of “show ssl ciphers will be:

Comparing these values with the table, you will see that they are the same.

You can check the same when using “fips, low, medium and high” keywords.


Here what you will see when you will change the values of the level:

When Change to fips:


When Change to Low:


When Change to Medium:


When Change to High:


When Change to All:


To specify the Diffie-Hellmann (DH) group to be used with DHE-RSA ciphers that are used by TLS, use the ssl dh-group command in global configuration mode. To return to the default, use the no form of this command.

Command Format :

ssl dh-group [ group1 | group2 | group5 | group14 | group24 ]

group1 Configures DH group 1 (768-bit modulus).



group14 Configures DH group 14 (2048-bit modulus, 224-bit prime order subgroup).



To specify the Diffie-Hellmann (DH) group to be used with DHE-RSA ciphers that are used by TLS, use the ssl dh-group command in global configuration mode. To return to the default, use the no form of this command.

Command Format :

ssl dh-group [ group1 | group2 | group5 | group14 | group24 ]






Groups 1 and 2 are compatible with Java 7 and earlier versions. Groups 5, 14, and 24 are not compatible with Java 7. All groups

are compatible with Java 8. Groups 14 and 24 are FIPS-compliant.

This command was introduced in 9.3(2) Version


To specify the group to be used with ECDHE-ECDSA ciphers that are used by TLS, use the ssl ecdh-group command in global configuration mode. To return to the default, use the no form of this command.

Command Format :

ssl ecdh-group [ group19 | group20 | group21 ]

group19 Configures group 19 (256-bit EC).



TLSv1.2 adds support for the following ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384

DHE-RSA-AES256-GCM-SHA384AES256-GCM-SHA384

ECDHE-ECDSA-AES256-SHA384ECDHE-RSA-AES256-SHA384

ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256

DHE-RSA-AES128-GCM-SHA256RSA-AES128-GCM-SHA256

ECDHE-ECDSA-AES128-SHA256ECDHE-RSA-AES128-SHA256

This command was introduced in 9.4(1) Version


Version TLS1.2 TLS1.1 SSLv3

8.6(1) X √ √9.0(1) X √ √9.0(2) X √ √9.0(3) X √ √9.0(4) X √ √9.1(1) X √ √9.1(2) X √ √9.1(3) X √ √9.1(4) X √ √9.1(5) X √ √9.1(6) X √ √9.2(1) X √ √9.2(2)4 X √ √

9.2(3) X √ √9.2(4) X √ √9.3(1) X √ √9.3(2) √ √ X

9.3(3) √ √ X

9.4(1) √ √ X

9.5(1) √ √ X


9.1.1


9.1.2 , 9.1.3 and 9.1.4


9.1.5 and 9.1.6


9.2(1) and 9.2(2)4


9.2(3) and 9.2(4)


9.3(1)


9.3(2) and 9.3(3)


9.4(1)


9.5(1)


• Starting form version 9.(2)1 you can enable the debug ssl command with level from 1 to 255

• Starting from 9.2(4) we can enable the following ssl debugs: debug ssl <1-255>debug ssl device <1-255>debug ssl ciphers <1-255>


You can enable the SSL Logging to see many logs related to the SSL Handshake and SSL errors. Commands:

#logging enable #logging class ssl monitored debugging --------- > This is used when using SSH, Telnet sessions #logging class ssl console debugging -------------- > This is used wen using console session

Output Example:


You can enable the SSL Logging to see many logs related to the SSL Handshake and SSL errors. Commands:

#logging enable #logging class ssl monitored debugging --------- > This is used when using SSH, Telnet sessions #logging class ssl console debugging -------------- > This is used wen using console session

Output Example:

Supported Ciphers by the ASA

Supported Ciphers by the ClientThey Finally agree to use

AES256-SHA


References


https://en.wikipedia.org/wiki/Transport_Layer_Security

http://crypto.stanford.edu/~nagendra/papers/dtls.pdf

http://www.cisco.com/c/en/us/support/docs/security-vpn/secure-socket-layer-ssl/116181-technote-product-00.html

VPN.642-648.Official.Cert.Guide.2nd.Edition Book


http://tools.ietf.org/html/rfc6101#section-5.5



http://tools.ietf.org/html/rfc4346https://tools.ietf.org/html/rfc5246

https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security

http://tools.ietf.org/html/rfc4347

http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/S/cmdref3/s16.html#pgfId-1421230

Intro to SSL, TLS and DTLS

Documents

Transcript of Intro to SSL, TLS and DTLS