Transport Layer Security (TLS), and its predecessor the Secure Sockets Layer (SSL), are protocols for securing exchanges over computer netwo...
Transport Layer Security (TLS), and its predecessor the Secure Sockets Layer (SSL), are protocols for securing exchanges over computer networks, particularly the Internet.
The SSL protocol was originally developed by Netscape Communications Corporation for its browser. The standards body IETF has continued to develop it and renamed it Transport Layer Security (TLS). SSL/TLS is sometimes referred to as either SSL or TLS.
TLS (or SSL) operates in a client-server mode. It makes it possible to satisfy the following security objectives :
- Server authentication ;
- The confidentiality of the data exchanged (or encrypted session);
- The integrity of the data exchanged;
- Optionally, client authentication (but in reality this is often ensured by the application layer).
The protocol is very widely used, and its implementation is facilitated by the fact that application layer protocols, such as HTTP, do not have to be profoundly modified to use a secure connection, but only implemented over SSL/TLS, which for HTTP has given rise to the HTTPS protocol.
A special IETF working group enabled the creation of the TLS and its UDP non-connected mode equivalent, the DTLS. Since its adoption by the IETF, the TLS protocol has been released in four versions: TLS v1.0 in 1999, TLS v1.1 in 2006, TLS v1.2 in 2008 and TLS v1.3 in 2018
Transport Layer Security :TLS to satisfy security needs
As the Internet developed, more and more commercial companies began to offer online shopping for individuals. The offer began to grow steadily, but the turnover generated by e-commerce remained modest as long as customers did not have sufficient confidence in paying by credit card. One of the ways to secure this payment was to use authentication and encryption protocols such as SSL. The encrypted session is used to prevent a third party from intercepting sensitive data passing through the network: card number when paying by credit card, password when the user identifies himself on a site...
With an SSL system, security has been significantly improved and the risks for the customer have been greatly reduced, compared to the time when internet payment was still an emerging technology. Although, like any encryption system, SSL/TLS can never be completely infallible, the large number of banks and e-commerce sites using it to protect their customers' transactions can be seen as a token of its resistance to malicious attacks.
In 2009, TLS is used by most web servers. The Internet user can recognize that a transaction is encrypted with several signs :
- The URL in the address bar starts with https ( https:// ;
- Display of a key or a padlock, the location of which varies according to the browser: generally to the left of the address bar but also in the lower bar of the window ;
- Browsers can add other signs, such as the address bar turning yellow (case of Firefox on older versions).
A glace at history
The first version of SSL released, SSL 2.0, had a number of security flaws, including the possibility of forcing the use of weaker encryption algorithms, a lack of contact protection and the possibility for an attacker to perform truncation attacks. The PCT 1.0 and then SSL 3.0 protocols were developed to solve most of these problems, with SSL 3.0 rapidly becoming the most popular protocol for securing Internet exchanges.
- 1994: SSL 1.0. This first specification of the protocol developed by Netscape remained theoretical and was never implemented.
- February 1995: publication of the SSL 2.0 standard, the first version of SSL actually in use. It was also the first implementation of banned SSL, in March 2011 (RFC 6176).
- November 1996: SSL 3.0, the latest version of SSL, which will inspire its successor TLS. Its specifications are reissued in August 2008 in RFC 61016. The protocol is banned in 2014, following the publication of the POODLE flaw, this ban is definitively ratified in June 2015 (RFC 7568).
The TLS protocol is not structurally different from SSL version 3, but changes in the use of hash functions mean that the two protocols are not directly interoperable. However, TLS, like SSLv3, does incorporate a mechanism for backward compatibility with previous versions, i.e. at the beginning of the negotiation phase, the client and server negotiate the "best" version of the protocol available to both. For security reasons, detailed in RFC 6176 issued in 2011, TLS compatibility with SSL version 2 is discontinued.
The generation of symmetric keys is a little more secure in TLS than in SSLv3 insofar as no step of the algorithm relies solely on MD5 for which weaknesses in cryptanalysis have appeared.
- January 1999: Publication of the TLS 1.0 standard. TLS is the protocol developed by the IETF to succeed SSL. Several improvements are made to it afterwards:
- October 1999: The Kerberos protocol is added to TLS ;
- May 2000: switch to TLS during an HTTP 1.1 session;
- June 2002: support of the AES encryption system by TLS.
- April 2006: publication of the TLS 1.1 standard.
- August 2008: publication of the TLS 1.2 standard.
- March 2011 (RFC 6176): abandonment of SSLv2 compatibility for all versions of TLS.
- April 2014: 1st draft for TLS 1.3.
- June 2015: Compatibility with SSLv2 and SSLv3 is discontinued.
- March 2018: New draft for TLS 1.3
- August 2018: publication of TLS 1.3. The main evolutions are the abandonment of the support of weak algorithms such as MD4, RC4, DSA or SHA-224, a negotiation in less steps (faster compared to TLS 1.2), and a reduction of the vulnerability to fall back attacks.
- The first professional release of TLS 1.3 is wolfSSL, released in May 2017.
Implementation of TLS
Most browsers are also TLS clients. The web browsers supporting by default the latest TLS 1.2 version are :
- Apple Safari 7 and later;
- Google Chrome and Chromium 30 and later;
- Microsoft Internet Explorer 11 and later;
- Mozilla Firefox 27 and later;
- Opera 17 and later;
- Microsoft Edge.
Leading web browser developers have announced that they will end their support for TLS 1.1 and earlier versions as of spring 2020.
HTTPS Everywhere is a web browser extension that extends the use of SSL/TLS to certain sites. It enables encryption on pages where it is normally disabled. This can of course only work if the site in question already supports TLS. The extension is maintained jointly by The Tor Project and the EFF since 2010.
Digital Certificate Authentication
In the majority of cases, the user authenticates the TLS server to which he connects. This authentication is performed using an X.509 digital certificate issued by a certification authority (CA). Web applications can use client authentication using TLS. It is then possible to offer mutual authentication between the client and the server. The client certificate can be stored in software format on the client workstation or provided by a hardware device (smart card, USB token). This solution makes it possible to offer strong authentication mechanisms.
Operating principle in web browsers
When a user connects to a web site that uses TLSv1.2 (or lower), the following steps occur :
- The client browser sends the server a request to set up a secure connection using TLS.
- The server sends to the client its certificate: it contains its public key, its information (company name, postal address, country, contact e-mail...) and a digital signature.
- The client's browser attempts to verify the digital signature of the server's certificate using the public keys contained in the certificates of the certification authorities (CA) integrated by default in the browser.
- If one of them works, the web browser derives the name of the CA that signed the certificate sent by the server. It checks that the certificate has not expired and then sends an OCSP request to the CA to verify that the server certificate has not been revoked.
- If none of these are working, the web browser attempts to verify the digital signature of the server certificate using the public key contained in the server certificate.
- If successful, this means that the web server has signed its own certificate. A warning message is then displayed on the web browser, warning the user that the identity of the server has not been verified by a certificate authority and that it may therefore be a potentially fraudulent site.
- If this fails, the certificate is invalid and the connection cannot be successful.
- The client browser generates a symmetric encryption key, called a session key, which it encrypts using the public key contained in the server certificate and then transmits this session key to the server.
- The server decrypts the session key sent by the client using its private key.
- The client and server begin exchanging data by encrypting the data with the session key they share. The TLS connection is then considered to be established between the client and the server.
- Once the connection is terminated (if the user disconnects voluntarily or if the user is idle for too long), the server revokes the session key.
Optional: If the server also requires the client to authenticate, the client sends the server its own certificate along with the session key. The server then proceeds as detailed in #3-4-5-6-7 to verify that the client's certificate is valid.
Since TLSv1.3, the exchange of the session key must obligatorily be done via Diffie-Hellman with elliptic curve (ECDHE): the RSA cannot be used any more for that.
In the TCP/IP protocol stack, SSL is located between the application layer (such as HTTP, FTP, SMTP, etc.) and the TCP transport layer.
Its most common use, however, is below HTTP. The SSL protocol is implemented by the session layer of the stack, which has two consequences:
- For any existing application using TCP, there can be an application using SSL. For example, the HTTPS application is HTTP over SSL or DNS over TLS ;
- An SSL application is assigned a new port number by IANA. For example, HTTPS is associated with port 443. In some cases, the same port is used with and without SSL. In this case, the connection is initiated in unencrypted mode. The tunnel is then set up using the StartTLS mechanism. This is the case, for example, with IMAP, SMTP or LDAP protocols.
Server and client authentication can be done through electronic certificates or through pre-shared keys . Authentication is optional.
Creating a TLS session 1.2
Messages exchanged via TLS are called records. Usually, these messages are encapsulated in TCP datagrams. A variant on UDP exists and is called DTLS. There are four types of records:
- Handshake messages are used to negotiate the TLS version, the cryptographic cipher suites used the compression algorithms, allow the sharing of a secret (or pre-master secret) and random data from which the session key (or master secret) will be generated to encrypt the data and, optionally, the authentication of the server and the client.
- Alert type messages provide errors and their severity: warning or fatal. Any fatal error results in the termination of the session.
- Change Cipher Spec messages indicate the change of cryptographic sequences in the exchanges.
- Application data messages are encrypted and compressed data according to the encryption and compression parameters previously established between the client and the server.
- · RFC 2246
- · RFC 2712
- · RFC 2817 and RFC 2818
- · RFC 3268
- · RFC 4346
- · RFC 5246
- · « The Transport Layer Security (TLS) Protocol Version 1.3 — draft-ietf-tls-rfc5246-bis-00 »