Transport Layer Security

Transport Layer Security (in English: Transport Layer Security or TLS) and its predecessor Secure Sockets Layer (SSL; in Spanish secure port layer) are cryptographic protocols, which provide secure communications over a network, commonly the Internet.

X.509 certificates and thus asymmetric cryptography are used to authenticate the counterparty with whom they are communicating, and to exchange a symmetric key. This session is then used to encrypt the data flow between the parties. This allows for data/message confidentiality, message authentication codes for integrity and as a side product, message authentication. Various versions of the protocol are in widely used 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 that the session's short-lived key cannot be discovered from the long-term asymmetric key.

TLS is a protocol of the Internet Engineering Task Force (IETF), first defined in 1999 and updated in RFC 5246 (August 2008) and RFC 6176 (March 2011). It builds on the previous SSL specifications (1994, 1995, 1996) developed by Netscape Communications to add the HTTPS protocol to their Netscape Navigator browser. Its latest version, TLS 1.3, was defined in August 2018.

Description

SSL provides authentication and data privacy between endpoints over the Internet through the use of cryptography. Typically, only the server is authenticated (that is, its identity is guaranteed) while the client remains unauthenticated.

SSL involves a series of basic phases:

• Negotiate between the parties the algorithm

to be used in communication

• Public key exchange and authentication based on digital certificates.
• Figure of traffic based on symmetric encryption.

During the first phase, the client and server negotiate which cryptographic algorithms to use. Current implementations provide the following options:

• For public key cryptography: RSA, Diffie-Hellman, DSA (Digital Signature AlgorithmOr Fortezza.
• For symmetrical encryption: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES and AES (Advanced Encryption Standard).
• With hash functions: MD5 or the SHA family.

History and development

Secure Network Programming API

Early research efforts toward transport layer security included the Secure Network Programming (SNP) application programming interface (API), which in 1993 explored the possibility of having a Secure transport layer API similar to Berkeley sockets, to make it easy to retrofit legacy network applications with security measures.

SSL 3.0

The SSL protocol was originally developed by Netscape. Version 1.0 was never released publicly; version 2.0 was released in February 1995 but "contained a number of security flaws that ultimately led to the design of version SSL 3.0". This version, released in 1996, was a complete redesign of the protocol produced by Paul Kocher, who worked with Netscape engineers Phil Karlton and Alan Freier. Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by the IETF as the landmark RFC 6101. In October 2014, a new vulnerability was detected on the SSL protocol in its version 3.0, the Poodle Vulnerability.

TLS 1.0

TLS 1.0 was defined in RFC 2246 in January 1999 and is an update to SSL version 3.0. As the RFC states, "the differences between this protocol and SSL 3.0 are not dramatic, but are significant enough to prevent interoperability between TLS 1.0 and SSL 3.0". TLS 1.0 includes a way in which the implementation can connect in SSL 3.0, weakening the security.

TLS 1.1

TLS 1.1 was defined in RFC 4346 in April 2006. It is an update to TLS 1.0. The most significant differences include:

• Add protection against CBC attacks.
  • The implied initialization vector (IV) was replaced by an explicit IV.
  • Change in handling of filling errors.
• Support for the registration of IANA parameters.

TLS 1.2

TLS 1.2 was originally defined in RFC 5246 in August 2008. It is based on a later specification of TLS 1.1. The biggest differences are:

• the MD5-SHA-1 combination in the pseudo-alearatory function (PRF) was replaced by SHA-256, with the option of using the PRF specified in the cipher-suite.
• the MD5-SHA-1 combination in the finished message was replaced by SHA-256, without the option to use algorithms hash specific for cipher-suite. However, the size of hash in the finished message is truncated to 96 bits.
• the MD5-SHA-1 combination in the digitally signed element was replaced by a hash simple negotiated during handshake, which by default is SHA-1.
• Improvements in client and server ability to specify which algorithms hash And they're going to accept.
• Expansion of authenticated encryption figures, used mostly for Galois/Counter mode (GCM) and CCM mode of encryption with Advanced Encryption Standard (AES).
• The definition of TLS and AES Ciphersuite extensions was added.

TLS 1.2 was later redefined in RFC 6176 of March 2011 writing its backward compatibility with SSL and TLS so that such sessions never negotiate the use of SSL version 2.0.

TLS 1.3

TLS 1.3 was defined in RFC 8446 in August 2018. It is based on the previous TLS 1.2 specification. The main differences with TLS 1.2 include:

• A mode 0-RTT
• Retreat of the GMT hour.
• It runs ECC support from RFC 4492 but without explicit curves.
• Remove the field of unnecessary length from AD entry to AEAD numbers.
• Change the name {Client, Server} KeyExchange to {Client, Server} KeyShare
• Add a HelloRetryRequest explicit to reject the client
• Handshake revised to provide 1-RTT mode.
• Retirement of custom DHE groups.
• Removed support for compression.
• Removed support for the exchange of static RSA and DH keys.
• Removed support for non-AEAD encryption systems.

Operation

The SSL protocol exchanges records; Optionally, each record can be compressed, encrypted and packaged with a message authentication code (MAC). Each record has a content_type field that specifies the top-level protocol being used.

When the connection is started, the record layer encapsulates another protocol, the handshake (or handshake) protocol, which has content_type 22.

The client sends and receives several handshake structures:

• Send a message ClientHello specifying a list of encryptions, compression methods and the version of the highest allowed SSL protocol. This also sends random bytes that will be used later (called Customer Challenge or Challenge). You can also include the session identifier.
• Afterwards, receive a record ServerHello, in which the server chooses the connection parameters from the options previously offered by the client.
• When the connection parameters are known, client and server exchange certificates (depending on the selected public encryption keys). These certificates are currently X.509, but there is also a draft specifying the use of OpenPGP-based certificates.
• Client and server negotiate a common (simetric) secret key called master secret, possibly using the result of a Diffie-Hellman exchange, or simply encrypting a secret key with a public key that is deciphered with everyone's private key. All remaining key data are derived from this master secret (and random values generated in the client and the server), which are passed through a pseudo-learning function carefully chosen.

TLS/SSL have a variety of security measures:

• Numerating all records and using the sequence number on the MAC.
• Using an improved message summary with a key (so that only the MAC can be checked with that key). This is specified in RFC 2104).
• Protection against several known attacks (including attacks) man-in-the-middle), such as those involving a degraded protocol to previous versions (thus less secure), or weaker encryption sets.
• The message that ends the protocol handshake (Finished) sends a hash of all data exchanged and seen by both parties.
• The pseudo random function divides the input data into 2 halves and processes them with algorithms hash different (MD5 and SHA), then performs on them an XOR operation. In this way it protects itself from the eventuality that any of these algorithms will reveal themselves vulnerable in the future.

Key exchange

Before a client and server can begin to exchange information protected by TLS, they must securely exchange or agree on an encryption key and a key to use when encrypting the data (see Encryption). Among the methods used for key exchange/agreement are: public and private keys generated with RSA (denoted TLS_RSA in the TLS handshake protocol), Diffie-Hellman (called TLS_DH), Diffie-Hellman ephemeral (denoted TLS_DHE), Elliptic Curve Diffie-Hellman (denoted TLS_ECDH), Elliptic Curve Ephemeral Diffie-Hellman (TLS_ECDHE), anonymous Diffie-Hellman (TLS_DH_anon), and PSK (TLS_PSK).

The TLS_DH_anon key agreement method does not verify the server or the user and is therefore rarely used as it is vulnerable to a spoofing attack. Only TLS_DHE and TLS_ECDHE provide perfect-forward-secret.

The public key certificates that are used during the exchange/agreement also vary in the size of the public/private encryption keys used during the exchange and therefore in the strength of the security they provide. In July 2013, Google announced that it would stop using 1024-bit public keys and switch to 2048-bit keys to increase the security of the TLS encryption it provides to its users.

Encryption

Notes

Data integrity

Message authentication code (MAC) is used to ensure data integrity. HMAC is used for the CBC mode of block ciphers and streams ciphers. AEAD is used for authenticated encryption such as GCM and CCM modes.

Applications and adoption

SSL runs on a layer between application protocols such as HTTP, SMTP, NNTP, and on top of the TCP transport protocol, which is part of the TCP/IP family of protocols. You can provide security for any protocol that uses trusted connections (such as TCP).

Websites

One of the most important uses is together with HTTP to form HTTPS. HTTPS is used to secure World Wide Web pages for e-commerce applications, using public key certificates to verify the identity of the endpoints.

Notes

Browsers

All major browsers support TLS:

Notes

Libraries

SSL and TLS have been widely implemented in various open and free software projects. Programmers can use the PolarSSL, CyaSSL, OpenSSL, MatrixSSL, NSS or GnuTLS libraries to have SSL/TLS functionality.

• Microsoft Windows includes SSL and TLS implementation as part of your Secure Channel package.
• OS X includes SSL and TLS implementation as part of your Secure Transport package.
• Delphi programmers can use a library called Indy.
• OpenSSL is a free implementation. You have a BSD license with some extensions.
• GnuTLS is a free implementation, with LGPL license.
• Zodiac TLS/SSL: is an implementation for Smalltalk with MIT license.
• cryptlib is open-sourced cryptographic library (which includes an SSL/TLS implementation).
• JSSE: a Java implementation included in the Java Runtime Environment that supports TLS 1.1 and 1.2 from Java 7, although it is by default disabled for the client and enabled on the server.
• MatrixSSL: a dual license implementation.
• Network Security Services (NSS): is an open source library validated for FIPS 140.
• PolarSSL is a very small SSL/TLS implementation for embedded devices that is designed for easy use.
• CyaSSL is an SSL/TLS library embedded with strong focus on speed and size.

A paper presented at the 2012 ACM conference on computer and communications security showed that many applications used these libraries incorrectly, leading to vulnerability. The authors noted that "the main cause of most of these vulnerabilities is the terrible design of the APIs for the underlying libraries. Instead of expressing high-level security properties for network tunnels such as confidentiality and authentication, these APIs expose low-level details of the SSL protocol to application developers. As a consequence, developers frequently use the SSL APIs incorrectly, misinterpreting and misunderstanding the possible parameters, options, side effects, and return values".

Other uses

Another application with increasing use of TLS is SMTP. TLS is also the standard method of protecting application signaling with Session Initiation Protocol (SIP). TLS can be used to provide authentication and encryption for signaling associated with VoIP and other SIP-based applications.

Although a growing number of client and server products can natively provide SSL, many still do not. In these cases, a user might want to use a standalone SSL application like Stunnel to provide encryption. However, the Internet Engineering Task Force recommended in 1997 that application protocols provide a way to upgrade to TLS from a plaintext connection (plaintext), rather than using a different port to encrypt. communications – this would avoid the use of wrappers such as Stunnel.

SSL can also be used to tunnel an entire network and create a virtual private network (VPN), as in the case of OpenVPN.

Security

SSL 2.0

SSL 2.0 has a variety of flaws:

• Identical cryptographic keys are used for authentication of messages and encryption.
• SSL 2.0 has a weak MAC construction that uses the function hash MD5 with a secret prefix, so it is vulnerable to long-range attacks.
• SSL 2.0 has no protection for the handshakeI mean, an attack. man-in-the-middle that is removed from this protocol can go unnoticed.
• SSL 2.0 uses the closure of the TCP connection to indicate the end of the data. This means that truncating attacks are possible: the attacker simply forges a FIN TCP, leaving the unconscious receiver of an illegitimate end of data message (SSL 3.0 solves this problem by having an explicit closing alert).
• SSL 2.0 assumes a single service and a fixed domain certificate, colliding with a standard function hosting virtual on Web servers. This means that most websites are practically affected by the use of SSL.

SSL 2.0 is disabled by default, as of: Internet Explorer 7, Mozilla Firefox 2, Opera 9.5, and Safari. After a "ClientHello" TLS, if Mozilla Firefox finds that the server cannot complete the handshake, it will try to fall back to using SSL 3.0 with an SSL 3.0 "ClientHello" in SSL 2.0 format to maximize the probability of handshake success with older servers. Allowing SSL 2.0 (and weak 40-bit and 56-bit encryption systems), has been completely removed from Opera since release. version 10

SSL 3.0

SSL 3.0 improved on SSL 2.0 by adding SHA-1 encryption and support for certificate authentication.

From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. SSL 3.0 cipher suites have a weak key derivation process, half of the master key that is set is totally dependent on the MD5 hash function, which is not crash resistant, and, therefore, it is not considered safe. Under TLS 1.0, the master key that is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak. It is for this reason that SSL 3.0 implementations cannot be validated under FIPS 140-2.

There are some attacks against the implementation rather than the protocol itself: In previous implementations, some CAs did not explicitly set basicConstraintsCA=False for leaf nodes. As a result, these leaf nodes could sign pirate certificates. Also, some programs (including IE6 and Konqueror) did not check this field at all. This can be exploited in man-in-the-middle attacks on all possible SSL connections. Some implementations (including older versions of the Microsoft Crypto API, Network Security Services, and GnuTLS) stop reading the characters that follow the null character in the certificate name field, which can be exploited to trick the client into reading of the certificate as if it originated from the authentic site. (For example, PayPal.com.badguy.com would be mistaken for coming from the PayPal.com site instead of badguy.com.) Browsers have implemented downgrade mechanisms in SSL/TLS for compatibility reasons. The protection offered by the SSL/TLS protocols against a downgrade to a previous version from an active man-in-the-middle attack can be rendered useless by such mechanisms.

TLS

TLS has a variety of security measures:

• Protection against a degradation of the protocol to an earlier (less secure) version or a weaker encryption set.
• Numeration of subsequent application records with a sequence number and the use of this sequence number in the message authentication codes (MAC).
• Using an improved message summary with a key (so only a key holder can check the MAC). HMAC construction used by most TLS encryption suites is specified in RFC 2104 (SSL 3.0 uses a MAC based on hash different).
• The message that ends the link protocol ("Finish") sends a hash of all messages exchanged handshake seen by both sides.
• The pseudo random function divides the input data into a medium and processes each with an algorithm hash different (MD5 and SHA-1), then make them OR exclusive together to create the MAC. This provides protection even if one of these algorithms turns out to be vulnerable.

Attacks against SSL/TLS

The most significant attacks are mentioned below:

Renegotiation Attack

A vulnerability in the procedure in which the renegotiation was discovered in August 2009, which can lead to plaintext injection attacks against SSL 3.0 and all current versions of TLS. For example, it allows an attacker who can hijack an https connection to splice his own requests into the beginning of the conversation the client is having with the web server. The attacker can't really decipher the client-server communication, so it's different from a typical man-in-the-middle attack. A short-term solution is for servers on the Internet to stop allowing renegotiation, which typically won't require any other changes unless client certificate authentication is used. To fix the vulnerability, an extension to the renegotiation indication was proposed for TLS. The client and server will be required to include and verify information about previous handshakes in any handshake renegotiation. has been assigned the number RFC 5746. The RFC has been implemented by several libraries.

Reversion attacks

There are modifications to the original protocols, such as False Start (approved and enabled by Google Chrome) or Snap Start, which have been reported to have introduced limitations to version reversion attacks for TLS or to allow that modifications to the ciphersuite list sent by the client to the server (an attacker may be able to influence the ciphersuite selection in an attempt to tone down the cipherplay intensity, either to use an algorithm weaker symmetric encryption or a weaker key exchange). It was demonstrated at the Association for Computing Machinery (ACM) Conference on Computer and Communications Security that the False Start extension is at risk under certain circumstances, which could allow an attacker to retrieve encryption keys online and gain access to the encrypted data.

BEAST Attack

On September 23, 2011, researchers Thai Duong and Juliano Rizzo demonstrated a “proof of concept” called BEAST ("Browser Exploit Against SSL/TLS") using a Java applet to violate policy restrictions. of same origin, for a widely known CBC vulnerability of TLS 1.0. Practical exploits of this vulnerability were not known, which was originally discovered by Phillip Rogaway in 2002.

Mozilla updated development versions of its NSS libraries to mitigate BEAST attacks. NSS is used by Mozilla Firefox and by Google Chrome for their implementation of SSL. Some web servers that have a broken implementation of the SSL specification may stop working as a result of this.

Microsoft issued security bulletin MS12-006 on January 12, 2012, which fixed the BEAST vulnerability by changing the way the Windows Secure Channel (SChannel) component transmits encrypted packets. For its part, Apple enabled protection against BEAST by default in OS X 10.9 Mavericks.

The BEAST attack can also be prevented by removing all CBC ciphers from the list of allowed ciphers, leaving only the RC4 cipher, which is widely supported by most websites. Windows 7 and Windows users Server 2008 R2 can allow the use of TLS 1.1 and 1.2, but this countermeasure will fail if it is not supported by the other end of the connection as well, and it will fall back to TLS 1.0.

CRIME and BREACH attacks

The authors of the BEAST attack are also the authors of the CRIME attack, which uses data compression for guessing. When used to retrieve the content of the secret authentication cookie, it allows an attacker to perform session hijacking on an authenticated web session.

Fill Attacks

Older versions of TLS were vulnerable to the oracle padding attack discovered in 2002. A new variant, called the Lucky Thirteen Attack, was released in 2013. As of February 2013, TLS implementers were still working on the development of solutions to protect against this form of attack.

A definitive solution was released as the Encrypt-then-MAC extension to TLS released as RFC 7366.

POODLE attack

On October 14, 2014, Google researchers published a vulnerability in the design of SSL 3.0, which makes the CBC mode of operation with SSL 3.0 vulnerable to the padding attack (CVE-2014-3566). They called this attack POODLE (Padding Oracle On Downgraded Legacy Encryption). On average, attackers only need to make 256 SSL 3.0 requests to reveal one byte of encrypted message.

Although this vulnerability only exists in SSL 3.0 and most clients and servers support TLS 1.0 and higher, all major browsers voluntarily downgrade to SSL 3.0 if they handshake with newer versions of TLS they fail unless they provide the option for a user or administrator to disable SSL 3.0 and the user or administrator does so. Therefore, the man-in-the-middle must first perform a rollback attack and then exploit this vulnerability.

In general, graceful security degradation for the sake of interoperability is difficult to accomplish in a way that cannot be exploited. This is especially challenging in domains where fragmentation is high.

RC4 Attack

Despite existing attacks on RC4 that break it, RC4-based cipher suites in SSL and TLS were considered secure at one point because the way the cipher was used in these protocols defeated attacks that broke RC4, until new attacks reported in March 2013 allowed RC4 on TLS to be completely broken. In 2011 it was recommended to use the RC4 suite as a workaround for the BEAST attack. In 2013 a vulnerability was discovered in RC4 suggesting that it was not a good solution for BEAST. A case of an attack was proposed by Alfardan, Bernstein, Paterson, Poettering, and Schuldt who used new statistical biases discovered in the RC4 keytable to recover parts of the plaintext with large numbers of TLS ciphers. A double-byte bias attack in RC4 on TLS and SSL that requires 13 × 220 ciphers to break RC4 was unveiled on July 8, 2013, and was described as "viable" in the accompanying presentation at the 22nd USENIX Security Symposium on August 15, 2013.

However, many modern browsers have been designed to defeat BEAST attacks (except Safari for Mac OS X 10.7 or earlier, for iOS 6 or earlier, and for Windows; see browsers). As a result, RC4 is no longer the best option for TLS 1.0. CBC ciphers that were affected by the BEAST attack in the past are becoming a more popular choice for protection.

Microsoft recommends disabling RC4 when possible.

Truncation Attack

A TLS truncation attack blocks disconnection requests from the victim's account so that the user unknowingly remains connected to a web service. When the end session request is sent, the attacker injects an unencrypted TCP FIN message (no more sender data) to close the connection. The server therefore does not receive the logoff request and is unaware of the abnormal termination.

Released in July 2013, the attack causes web services such as Gmail and Hotmail to display a page informing the user that they have successfully exited the service, while ensuring that the user's browser maintains authorization with the service, allowing an attacker the access to take control of the account that the user is logged in to. The attack is not based on the installation of malware on the victim's computer; attackers only need to get between the victim and the web server (for example, by creating a rogue wireless access point). This vulnerability also requires access to the victim's computer.

Heartbleed Glitch

The Heartbleed flaw is a serious vulnerability in the popular OpenSSL cryptographic software library, affecting versions 1.0.1 to 1.0.1f. This weakness allows the theft of information protected, under normal conditions, by the SSL / TLS encryption used to secure data uploads. SSL/TLS provides communications security and privacy over the Internet for applications such as the web, email, instant messaging (IM), and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of systems protected by vulnerable versions of OpenSSL software. This compromises the secret keys used to identify service providers and to encrypt traffic, user names and passwords, and actual content. This allows attackers to eavesdrop on communications, steal data directly from services and users, and impersonate services and users.

Website study

As of December 2014, the Trustworthy Internet Movement estimates the proportion of websites that are vulnerable to TLS attacks.

Forward secrecy

Forward secrecy is a property of cryptographic systems that guarantees that a session key derived from a set of public and private keys will not be compromised if one of the private keys is compromised in the process. Without forward secrecy, if the server's private key were known, not only all future TLS-encrypted sessions using that server's certificate would be compromised, but also previous sessions that used it (provided of course that these past sessions were intercepted and stored at the time of transmission). A TLS implementation can provide forward secrecy by requiring the use of ephemeral Diffie-Hellman key exchanges to establish session keys, and some notable TLS implementations do so exclusively: for example, Gmail, and other Google services that use HTTPS OpenSSL. However, many clients and servers that support TLS (including browsers and web servers) are not configured to enforce those restrictions. In practice, unless a web service uses Diffie-Hellman to implement forward secrecy, all encrypted web traffic to and from that service can be decrypted by a third party if it obtains the master key of the server (private); for example, through a court order.

Even when Diffie-Hellman key exchange is implemented, session management mechanisms on the server can affect forward secrecy. The use of TLS session tickets (a TLS extension) means that the session must be protected by AES128-CBC-SHA256 regardless of any other negotiated TLS parameters, including forward secrecy cipher suites, and ticket keys. long-running TLS session breaks the attempt to implement forward secrecy.

Since late 2011, Google has provided forward secrecy with TLS by default for users of its Gmail service, along with Google Docs and encrypted search, among other services. Since November 2013, Twitter has provided forward secrecy with TLS for users of its service. As of December 2014, 20.0% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to web browsers.

Avoid Triple-DES CBC

Some experts recommend avoiding Triple-DES CBC. Because RC4 and Triple-DES are the last ciphers supported in the Windows XP SSL/TLS libraries, it makes it difficult to support SSL for programs using this library on Windows XP. For example in the case of Internet Explorer for Windows XP.

Coping with MITM attacks

Certificate Pinning

One way to detect and block many types of MITM attacks is to "pin the certificate," sometimes called "SSL pinning".

A client doing certificate pinning adds an extra step to the usual SSL protocol or TLS protocol: After obtaining the server's certificate in the standard way, the client checks the server's certificate against the trusted data for validation. Trust validation data is typically included with the application, in the form of a trusted copy of that certificate, or a trusted hash or thumbprint of the certificate, or the public key of the certificate. For example, Chromium and Google Chrome include validation data for the *.google.com certificate which detects fraudulent certificates in 2011. Mozilla has since introduced public certificate pinning in its Firefox browser.

In other systems the client expects that the first time it obtains the certificate from a server it is trusted and stores it; during subsequent sessions with that server, the client checks the server's certificate against the stored certificate to protect against subsequent MITM attacks.

Project Perspectives

The Perspectives Project operates network notaries that clients can use to detect if a site's certificate has changed. By their nature, man-in-the-middle attacks place the attacker between the destination and a single specific target. As such, Insights would warn the target that the certificate delivered to the web browser does not match the certificate seen from other perspectives - the perspectives of other users at different times and places. Using network notaries from a multitude of perspectives makes it possible for a target to detect an attack even if a certificate appears to be completely valid.

Protocol Details

The TLS protocol exchanges records - those that encapsulate the data being exchanged in a specific format (see below). Each record can be compressed, encrypted and packed with a MAC (Message Authentication Code) code, all depending on the state of the connection. Each record has a content-type field designating the encapsulated data type, a length field, and a TLS version field. The encapsulated data can be control or procedural messages from TLS itself, or simply the application data that needs to be transferred over TLS. The specifications (cipher suite, keys, etc.) necessary for the exchange of application data over TLS have been agreed in the "TLS handshake" between the client requesting the data and the server responding to the requests. Thus, the protocol defines both the structure of payloads transferred in TLS and the procedure to establish and monitor the transfer.

TLS Handshake

When the connection is initiated, the record encapsulates a "control" protocol - the handshake messaging protocol (content type 22). This protocol is used for the exchange of all the information required by the two parties for the exchange of the data of the real applications by TLS. It defines the format messages or messages that contain this information and the order of their exchange. These can vary depending on the demands of the client and the server, that is, there are several possible procedures to establish the connection. This initial exchange results in either a successful TLS connection (both parties ready to transfer application data with TLS) or an alert message (as specified below).

Basic Handshake

The following is a simple connection example, illustrating a handshake in which the server (but not the client) is authenticated by its certificate:

1. Negotiation phase:
   • A client sends a message ClientHello specifying the highest version of TLS protocol it supports, a random number, a list of suggested encryption assemblies and compression methods. If the client is trying to perform a handshake resumed, you can send a session ID.
   • The server responds with a message ServerHello, which contains the version of the chosen protocol, a random number, CipherSuite and compression method of the options offered by the client. To confirm or allow handshake resumed server can send a session ID. The version of the chosen protocol should be the highest of both client and server support. For example, if the client is compatible with version 1.1 and the server is compatible with version 1.2, version 1.1 should be selected; 1.0 should not be selected.
   • The server sends your certificate message (depending on the selected encryption suite, this can be omitted by the server).
   • The server sends your message ServerKeyExchange (depending on the selected encryption set, this can be omitted by the server). This message is sent to all DHE and DH_anon encryption assemblies.
   • The server sends a message ServerHelloDoneWhich indicates he ended up with the handshake negotiation.
   • The customer responds with a message ClientKeyExchangewhich may contain a PreMasterSecret, the public key, or nothing. (Once again, this depends on the selected number.) This PreMasterSecret is encrypted using the public key to the server certificate.
   • The client and the server then use the random numbers and PreMasterSecret to calculate a common secret, called the "main secret" (master secret). All the other key data for this connection is derived from this main secret (and random values generated by both client and server), which are passed through a carefully designed pseudo-alearning function.
2. The client now sends a record ChangeCipherSpecessentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if the encryption parameters were present on the server certificate)." The ChangeCipherSpec itself is a protocol at the registration level with the content type 20.
   • Finally, the client sends an authenticated and encrypted message Finished (third) containing a hash and MAC on messages handshake previous.
   • The server will try to decipher the message Finished and verify the hash and MAC. If the decryption or verification fails, the handshake it is considered to have failed and the connection must be knocked down.
3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if the encryption was negotiated). "
   • The server sends your message Finished authenticated and encrypted.
   • The customer performs the same decryption and verification.
4. Application phase: at this point, the "handshake" is completed and the application protocol is activated, with the content type of 23. The application messages exchanged between the client and the server will also be authenticated and optionally encrypted exactly as in their final message. Otherwise, the content type will answer 25 and the customer will not be authenticated.

Client authenticated TLS handshake

The following complete example shows a client being authenticated (in addition to the server as above) via TLS using certificates exchanged between both parties.

1. Negotiation phase:
   • A client sends a message ClientHello specifying the highest version of TLS protocol it supports, a random number, a list of suggested encryption assemblies and compression methods.
   • The server responds with a message ServerHello, which contains the chosen version of the protocol, a random number, a encryption suite and the compression method of the options offered by the client. The server can also send a login identifier as part of the message to perform a handshake resumed.
   • The server sends your certificate message (depending on the selected encryption suite, this can be omitted by the server).
   • The server sends your message ServerKeyExchange (depending on the selected encryption set, this can be omitted by the server). This message is sent to all DHE and DH_anon encryption assemblies.
   • The server requests a certificate from the client, so that the connection can be mutually authenticated, using a message CertificateRequest.
   • The server sends a message ServerHelloDoneWhich indicates it ended with handshake negotiation.
   • The customer responds with a certificate message, which contains the customer's certificate.
   • The client sends a message ClientKeyExchangewhich may contain a PreMasterSecretpublic key, or nothing. (Once again, this depends on the selected encryption.) This PreMasterSecret is encrypted using the public key to the server certificate.
   • The client sends a message CertificateVerify, which is a signature on the previous reconnaissance messages using the customer certificate's private key. This signature can be verified using the public key to the customer certificate. This allows the server to know that the customer has access to the certificate's private key and therefore has the certificate.
   • The client and the server then use random numbers and PreMasterSecret to calculate a common secret, called the "main secret." All other key data for this connection are derived from this master secrecy (and the client-and-generated random values of the server), which is passed through a carefully designed pseudo- random function.
2. The client now sends a record ChangeCipherSpecessentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if the encryption was negotiated)." The ChangeCipherSpec itself is a protocol at the registration level and is type 20 and not 22.
   • Finally, the client sends an encrypted message Finishedcontaining a hash and MAC on messages handshake previous.
   • The server will try to decipher the client's final message and verify the hash and MAC. If the decryption or verification fails, the handshake it is considered to have failed and the connection must be knocked down.
3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if the encryption was negotiated). "
   • The server sends its own encrypted message Finished.
   • The customer performs the same decryption and verification.
4. Application phase: at this point, the "handshake" is completed and the application protocol is activated, with the content type 23. The app messages exchanged between the client and the server will also be encrypted exactly as in your message Finished.

Handshake resumed

Public key operations (for example, RSA) are relatively expensive in terms of computation. TLS provides a secure shortcut in the handshake mechanism to prevent these operations: resuming sessions. Resumed sessions are implemented using session IDs or session tickets.

Apart from the performance advantage, resuming sessions can also be used for single sign-on, since both the original session as well as any resumed sessions are guaranteed to originate from the same client. This is of particular importance for FTP over the TLS/SSL protocol, as it could otherwise suffer from a man-in-the-middle attack where an attacker could intercept the content of secondary data connections.

Session IDs

In a normal full handshake, the server sends a session ID as part of the ServerHello message. The client associates this session ID with the server's IP address and TCP port, so that when the client connects to that server again, it can use the session ID to shorten the handshake. On the server, the session ID is mapped to previously negotiated cryptographic parameters, specifically the "master secret". Both parties must have the same "master secret" or the resumed handshake will fail (this prevents a spy from using a session ID). The random data in the ClientHello and ServerHello messages practically guarantees that the generated connection keys will be different from the previous connection. In the RFCs, this type of handshake is called an abbreviated handshake. It is also described in the literature as a handshake reset.

1. Negotiation phase:
   • A client sends a message ClientHello specifying the highest version of TLS protocol it supports, a random number, a list of suggested encryption assemblies and compression methods. Included in the message is the session ID of the previous TLS connection.
   • The server responds with a message ServerHello, which contains the chosen version of the protocol, a random number, a encryption suite and the compression method of the options offered by the client. If the server recognizes Session ID, respond with the same Session ID. The client uses this to recognize that a resumed session is being held. If the server does not recognize Session ID sent by the customer, responds with a different value for the Session ID, which tells the client that a resumed session will not be held. At this point, both the client and the server have the "master secret" and random data to generate the key used for this connection.
2. The server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if the encryption was negotiated). "
   • Finally, the server sends an encrypted message Finishedcontaining a hash and MAC on messages handshake previous.
   • The customer performs the same decryption and verification.
3. The client now sends a record ChangeCipherSpecessentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if the encryption was negotiated). "
   • The customer sends his own encrypted message Finished.
   • The server will try to decipher the client's final message and verify the hash and MAC.
4. Application phase: at this point, the "handshake" is completed and the application protocol is activated, with the content type 23. The app messages exchanged between the client and the server will also be encrypted exactly as in your message Finished.

Session Tickets

RFC 5077 extends TLS through the use of session tickets, instead of session IDs. Defines a way to resume a TLS session without needing to store the session-specific state on the TLS server.

When using session tickets, the TLS server stores its specific session state in a session ticket and sends the session ticket to the TLS client to be stored. The client resumes a TLS session by sending the session ticket to the server, and the server resumes the TLS session in the session-specific state in the ticket. The session ticket is encrypted and authenticated by the server, and the server checks its validity before using its content.

A particular weakness of this method with OpenSSL is that it always limits the encryption and security authentication of the transmitted TLS session ticket to AES128-CBC-SHA256, no matter what other TLS parameters are negotiated for the current TLS session. This means that the state information (the TLS session ticket) is not as well protected as the TLS session itself. Of particular concern is OpenSSL's storage of keys in an application context (SSL_CTX), i.e. it is maintained for the lifetime of the application, and does not allow re-entry of AES128-CBC-SHA256 session ticket information. TLS without restarting the OpenSSL application-level context (which is rare, error-prone, and often requires manual administrative intervention).

TLS Record

This is the general format for all TLS records.

Content type

This field identifies the Protocol Registration Layer Type contained in this registry.

Version

This field identifies the larger and smaller version of TLS for the content message. For a ClientHello message, this doesn't have to be the version higher admitted by the client.

Length

The length of the Protocol's message (s), MAC and Filling, which does not exceed 214 bytes (16 KiB).

Message Protocol

One or more messages identified by the Protocol field. Please note that this field can be encrypted depending on the status of the connection.

MAC and Filling

A calculated message authentication code on the Protocol message, with the additional key material included. Note that this field can be encoded, or not fully included, depending on the status of the connection.

No MAC or filler may be present at the end of the TLS records before all encryption algorithms and parameters have been negotiated and handshaked and then confirmed by sending a CipherStateChange registry (see below) for signaling these parameters will have effect on all additional records sent by the same pairs.

Handshake Protocol

Most messages exchanged during TLS session setup are based on this log, unless an error or warning occurs and needs to be signaled by an alert protocol log (see below), or the The session's encryption mode is modified by another record (see the ChangeCipherSpec protocol below).

Type of Message

This field identifies the type of message from handshake.

Handhake message data length

This is a 3-byte field that indicates the length of handshake data, not including the header.

Note that multiple handshake messages can be combined within one record.

Alert protocol

This record should not normally be sent during normal application or handshake exchanges. However, this message can be sent at any time during the handshake and up to the end of the session. If this is used to signal a fatal error, the session will be closed immediately after this record is sent, so this record is used to give the reason for this closure. If the alert level is marked as a warning, the remote can decide to close the session if it decides that the session is not reliable enough for its needs (before doing so, the remote can also send its own signal).

Level

This field identifies the alert level. If the level is fatal, the sender must close the session immediately. Otherwise, the recipient may decide to terminate the session by sending his own fatal alert and closing the session itself immediately after sending it. The use of alert logs is optional, however if it is not before the session closes, the session can be automatically resumed (with your handshake).

The normal closing of the session after the termination of the transported application should be alerted preferably with at least the type of alert Close notify (with a simple warning level) to prevent the new session from being resumed. The explicit signaling of the normal closing of a safe session before effectively closing your transport layer is useful for preventing or detecting attacks (such as attempts to truncate data safely transported, if intrinsically it does not have a default length or duration that the data recipient can expect).

Description

This field identifies which kind of alert is being sent.

ChangeCipherSpec Protocol

Type of CCS Protocol

Currently only 1.

Application protocol

Go!

Length of application data (excluding protocol header and including MAC end and filling)

MAC

20 bytes for HMAC based on SHA-1, 16 bytes for HMAC based on MD5.

Filling

Variable length; the last byte contains the length of the filling.

Support for virtual servers by name

From an application protocol point of view, TLS belongs to a low layer, although the TCP/IP model is too thick to show it. This means that the handshake is usually (except in the STARTTLS case) performed before the application protocol can start. Name-based virtual server functionality is provided by the application layer, where all virtual servers hosted on the same machine share the same certificate. This is a problem, since the server must select and send the certificate immediately after the ClientHello message. This is a big problem in hosting environments, since it implies that all clients on the same server must share the certificate or a different IP must be used for each one of them. There are two known ways around this, provided by X.509:

• If all virtual servers belong to the same domain, a wild certificate can be used. In addition to a problem the wide selection of host ame, there is no agreement on how to pair wildcard certificates. Different rules apply depending on the application protocol or the used software.
• Add each virtual host in the extension subjectAltName. The biggest problem of this is that the certificate needs to be forwarded every time a new server is added.

In order to provide the server name, RFC 4366 Transport Layer Security (TLS) Extensions allow the client to include a Server Name Indication (SNI) extension in the extended ClientHello message. This extension immediately hints to the server as to which name the client wants to connect to, so the server can select the appropriate certificate to send to the client.

Standards

TLS 1.0

Extensions to TLS 1.0 include:

• RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. It specifies an extension to IMAP, POP3 and ACAP services that allow the client and server to use security in the transport layer to deliver private and authenticated communications on the Internet.
• RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". The 40-bit encryption families defined in this memo appear only for documentation purposes of the fact that these encryption code families have already been assigned.
• RFC 2817: "Upgrade to TLS Within HTTP/1.1", explains how to use the Upgrade mechanism on HTTP/1.1 to start TLS on an existing TCP connection. This allows HTTP traffic unsafe and secure to share the same port known (in this case, http: 80 instead of https: 443).
• RFC 2818: "HTTP Over TLS", differentiates safe traffic insecure by using a different 'server'.
• RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Specifies an extension to the SMTP service that allows the SMTP client and server to use security in the transport layer to deliver private and authenticated communications on the Internet.
• RFC 3268: "AES Ciphersuites for TLS". Add the AES encryption family to previously existing symmetric encryptions.
• RFC 3546: "Transport Layer Security (TLS) Extensions", adds a mechanism to negotiate protocol extensions during login and defines some extensions.
• RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the framework for compression methods and the DEFLATE method.
• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.
• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4217: “Securing FTP with TLS”.
• RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", adds three sets of new encryption families so that the TLS protocol allows authentication based on previously shared keys.

TLS 1.1

Extensions to TLS 1.1 include:

• RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works on datagram protocols (such as UDP).
• RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of specific extensions and a generic extension mechanism.
• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.
• RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.
• RFC 4680: “TLS Handshake Message for Supplemental Data”.
• RFC 4681: “TLS User Mapping Extension”.
• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.
• RFC 5054: “Using the Secure Remote Password (SRP) Protocol for TLS Authentication”. Define the TLS-SRP cihpersuites.
• RFC 5081: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication”, obsolete after RFC 6091.

TLS 1.2

The current approved version of TLS is 1.2, which is specified in:

• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2.”

The current standard supersedes older versions, which are considered obsolete:

• RFC 2246: “The TLS Protocol Version 1.0”.
• RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1.”

as well as the never standardized SSL 3.0:

• RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”.

Subsequent RFCs extended TLS.

Extensions to TLS 1.2 include:

• RFC 5746: “Transport Layer Security (TLS) Renegotiation Indication Extension”.
• RFC 5878: “Transport Layer Security (TLS) Authorization Extensions”.
• RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“.
• RFC 6176: “Prohibiting Secure Sockets Layer (SSL) Version 2.0”.
• RFC 6209: “Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)”.

TLS 1.3

• RFC 8446 in English The Transport Layer Security (TLS) Protocol Version 1.3.

Encapsulations

TLS encapsulations include:

• RFC 5216: "The EAP-TLS Authentication Protocol"