SSL Technique

This article describes the encryption protocols SSL and TLS and the TLS Handshake that is required for setting up an HTTPS connection.

SSL and TLS

The encryption protocols Secure Sockets Layer (SSL) and it's sibling Transport Layer Security (TLS) are used to protect the communication on the internet. SSL was originally developed by Netscape, and after a number of improvements it evolved to SSL v3, which added extra protection against the eavesdropping and falsification of messages. Although SSL is the most used term, the terms SSL and TLS are often used as interchangeable. The protocols provide for:

Authentication of the server (for example the server of a webshop) and optionally the client (for example the browser of the visitor) with the help of an SSL certificate. Asymmetrical encryption is used in this stage.
Guaranteeing privacy by encrypting the exchanged data, based on a changing, symmetric key.
Ensuring integrity; as soon as data changes, the connection is broken.

TLS Handshake Procedure

Setting up a TLS connection is done in a number of steps. In most cases, the entire procedure takes no more than a second.

When the client and server have decided to use the TLS connection (often port 443 for HTTPS is used for this) the connection is further established by means of a 'handshake' procedure. During this handshake, the client and the server agree with various parameters to establish a secure connection:

Before the SSL connection is set up, the client and the server exchange data, for example the strongest algorithm and the most recent SSL / TLS protocol, which they both support.
The server sends proof of its identity in the form of a digital certificate (the public key of the certificate), which the client checks for validity. This way the client knows with whom he communicates. In the case of double-sided SSL, the server also requests a digital certificate to the client, so that both the server and the client know with whom they communicate.
The client uses information provided by the server to verify the server. If the server can not be verified, the user is warned that no encrypted connection can be established. Only when the server can be successfully verified, the client will proceed to the next step.
The client encrypts a random number with the public key of the certificate that it received in step 2 from the server; this becomes a so-called session-specific pre-master secret. The client sends these to the server, which can only decipher the pre-master secret because it has the private key of the certificate used. Because only the two parties mentioned have access to the used keys, abuse by third parties can be excluded.
If the server has requested client authentication (in the case of two-sided SSL, an optional step in the handshake), the client will sign another unique piece of data. This data is unique to this handshake and is known to both the client and the server. In this case, the client sends the signed data, the client's own certificate and the encrypted pre-master secret to the server.
If the client can not be verified, the session is closed. If the client can be successfully verified, the server will use its private key to decrypt the pre-master secret. Then both the client and the server perform a series of steps to generate a master secret based on the pre-master secret.
Both the client and the server use the master secret to generate session keys. These are symmetric keys used for encoding and decoding information that is exchanged during the SSL session and for checking integrity (that is, to detect any changes in the data between sending and receiving the data over the SSL link).
The client sends a message to the server. This indicates that future messages from the client are encrypted with the session key. The client then sends a separate encrypted message indicating that the client part of the handshake has been completed.
The server sends a message to the client. This indicates that future messages from the server are encrypted with the session key. The server then sends a separate encrypted message indicating that the server part of the handshake has been completed.

The SSL handshake is now complete and the session begins. The client and server now use the session keys to encrypt, decrypt, and verify the integrity of data. For every session (such as visiting website) the handshake process is re-executed and new keys are used.

History

When setting up a secure connection, the client and server negotiate a common protocol to protect the channel during the handshake. Various versions of SSL and TLS have been developed; the most recent version is TLS 1.3.

SSL 1.0, 2.0 and 3.0

The first SSL 1.0 technology was developed by Netscape in 1994. Due to serious security problems, this version has never been published. In 1995, Netscape published SSL 2.0. The vulnerabilities of the previous version have been improved, but SSL 2.0 still had a number of cryptographic weaknesses. Once again Netscape published SSL 3.0 in 1996, developed by Paul Kocher. In this version the protocol has been completely rewritten and all security weaknesses have been restored. In 2014 another serious weakness was discovered in SSL 3.0.

PCT 1.0

Private Communications Technology (PCT) 1.0 is a protocol developed by Microsoft in the 90s. PCT is designed to address security flaws in version 2.0 of Netscape's Secure Sockets Layer (SSL) protocol and Netscape enforces ownership and control of SSL convert the protocol to an open standard. PCT is now an outdated protocol and replaced by SSLv3 and TLS. PCT was temporarily supported by Internet Explorer, but the latest versions no longer support PCT. The PCT protocol is still in IIS and the system library of Windows operating systems but is disabled by default.

TLS 1.0

TLS 1.0 was first described in RFC 2246 in January 1999 as an upgrade of SSL 3.0. Although there are no significant differences between TLS 1.0 and SSL 3.0, the protocols could not cooperate. In addition, with TLS 1.0 it was possible to set up an SSL 3.0 connection, which weakened security. In 2011, this version was cracked by Thai Duong and Juliano Rizzo, making this version unusable as a secure protocol.

TLS 1.1

TLS 1.1 was published in April 2006 and described in RFC4346. TLS 1.1 is an update and further development of version 1.0. This version offers several improvements, such as improved security and handling of errors. Despite the improved functionality, this version is hardly used.

TLS 1.2

TLS 1.2 was published in August 2008, and described in RFC5246. TLS 1.2 is a further development of version 1.1 with a number of significant improvements including:

Used cryptographic hashes, which have proved unsafe, have been replaced by SHA-256.
Improved support for more modern encryption methods from the Advanced Encryption Standard.
Fallback compatibility with the unsafe SSL 2.0 removed.

TLS 1.3

TLS 1.3 development was completed in March 2018 and the Request for Change was published on August 10, 2018. The browsers Chrome and Firefox support the protocol from version 56 and 52 respectively. In January 2021, the National Cyber Security Center adjusted its advice to 1.3, whereby the status of 1.2 was adjusted down from good to sufficient. TLS 1.3 is more resistant to (future) attack techniques and is also easier to configure securely than its predecessor TLS 1.2, and most software libraries now support the protocol.

TLS 1.3 is a further development of version 1.2 with a number of important improvements, including:

Increased speed, compared to the previous version only one round trip is required.
Enhanced security, obsolete and insecure features such as SHA1 and MD5 have been removed.