What is TLS SSL Protocol? - JohnHau/mis GitHub Wiki

1. What is SSL, TLS, and HTTPS? SSL (Secure Socket Layer) and TLS (Transport Layer Security) are popular cryptographic protocols that are used to imbue web communications with integrity, security, and resilience against unauthorized tampering. PKI uses the TLS protocol to establish secure connections between clients and servers over the internet, ensuring that the information relayed is encrypted and unable to be read by an external third party.

Note: SSL was the predecessor of TLS, and the world began moving away from SSL once TLS was introduced in 1999, thanks to the improved security features of the latter. TLS is currently in its third iteration, and is called TLS 1.3. However, SSL continues to be used as a metonym for both protocols in general (for example, the word ‘SSL certificate’ is widely used, but SSL has been completely deprecated and no modern systems support SSL anymore).

Connections that are secured by TLS will indicate their secure status by displaying HTTPS (Hypertext Transfer Protocol Secure) in the address bar of web browsers, as opposed to just HTTP.

While TLS is primarily used to secure client-server connection, it is also used to protect emails, VoIP calls, and other connections.

1.1. Why are they necessary? In theory, web connections are completely possible without TLS to secure them. However, without a security protocol in place, the communication would be rendered completely open to external access. If a browser connected to the website of an online store, and a user had to enter their credentials to log in, those credentials could easily be lifted by an observing party.

TLS, at its core, serves to provide end-to-end encryption for all data transmitted from one point to another, and uses cryptography to ensure that only the two transacting bodies are capable of reading this information. Every service in the world now mandates that connections are secure by TLS – leading browsers do not allow users to access websites without a valid TLS connection.

TLS has the following benefits:

The contents of the connection remain encrypted, private, and fully secure – and cannot be easily deciphered by malicious actors. The connection is only made if it is reliable – this reliability check is a part of TLS communications, and is enforced by the exchange of a Message Authentication Code. The use of PKI and TLS certificates ensures that the identities of both communicating parties are verified.

2. How does SSL/TLS work? 2.1. The TLS Handshake When two systems that leverage TLS attempt to connect, each system will make an effort to verify that the other supports TLS. This process is called the TLS handshake, and it is here that both parties decide upon the TLS version, encryption algorithm, cipher suite etc. that will be used in the procedure. Once a TLS handshake has been successfully executed, both systems start exchanging data on a secure line.

Note: A working knowledge of PKI and its constituents, such as keys, may prove to be useful prior to understanding TLS. You can read more about it in the link above. For now, all you need to know is that encryption and decryption are carried out with the help of cryptographic devices called keys. In public key cryptography, Public keys are used to encrypt information, while secret Private keys can be used to decrypt that information. Since two different keys are involved, this technique is called ‘asymmetric cryptography’, as opposed to ‘symmetric cryptography’, where a single key can perform both encryption and decryption. More on this below.

Every TLS handshake follows the same basic steps. For the sake of simplicity, let’s assume a browser (a client) is attempting to connect to a server, which hosts a website:

The client requests the server to open a secure line, and the server responds by displaying a list of TLS versions and cipher suites it is compatible with. Once they agree upon common ones to use in the transaction, they begin the handshake. The server sends a copy of its public key, attached to its digital certificate, to the client. The client checks the certificate to verify that the server is legitimate, and if it is, proceeds with the transaction. The client uses the server’s public key and its private key to encrypt a ‘session key’ which is a key that will be used by both parties to encrypt and decrypt information in this particular session. The session key becomes invalid as soon as the connection is terminated. Both parties test the connection by sending each other encrypted messages. If the other can decrypt them using the session key, the connection has been successfully secured.

2.2. Asymmetric vs. Symmetric Encryption The above example was an instance where both asymmetric and symmetric encryption was used to secure a connection.

Asymmetric encryption was used to create the session key. But from that point onwards, the session key was used to bilaterally encrypt and decrypt the entire information flow between both parties. Here’s why:

Asymmetric encryption is mathematically resource-intensive. The encryption-decryption operations involving two keys from both parties takes a heavy toll on the processing unit powering this process. If a system were configured to handle an entire connection this way – by using a public key to encrypt and a private key to decrypt it – it would probably give out within the first few minutes. It’s much more secure than its symmetric counterpart, but cannot be facilitated in an efficient manner.

However, symmetric encryption, which makes use of a single, shared key to encrypt and decrypt, is not that resource-intensive. This is precisely why asymmetric encryption is used to establish a secure link between two parties, and used to generate the session key which, in theory, only those two parties can possibly know about. Now, symmetric encryption can be used to secure the connection, given the additional layer of security added to it by the first step.

3. SSL/TLS certificates? 3.1. What are SSL/TLS certificates? Digital certificates were mentioned earlier in this article. In general, digital certificates are digital documents that are ‘signed’ by trusted authorities, and act as documents of ownership of a public key. By extension, they serve to validate the legitimacy of a server or a client. However, there are several types of digital certificates available. The term ‘x.509 certificates’ is used to differentiate SSL/TLS certificates with other kinds of digital certificates (code-signing certificates, for instance).

Let’s take a look at why they’re necessary.

As the previous section made clear, digital certificates are important pieces in the public key cryptography domain. They’re attached to public keys, and are proof that the holder of the public key is actually the legitimate owner. This is because digital certificates are signed, sold, and issued by bodies called ‘Certificate Authorities’ (or CAs, for short), which are trusted bodies responsible for verifying the authenticity of anyone who requests a certificate. Since major operating systems and browsers have ‘trust stores’ consisting of these CAs built into them, browsers will automatically trust certificates issued by major CAs.

Certificates are key to making websites easily recognizable to users as a trusted, secure page. Webpages with valid SSL/TLS certificates installed on them will have ‘https’ preceding the name of the website in the search bar, given that the certificate has been installed correctly. In some browsers, the use of a valid Extended Validation certificates (a type of TLS certificate), will cause the HTTPS padlock to turn green, providing visitors with additional assurance that they are on a legitimate website, like so:

Note: The certificates issued by CAs which are used to secure web connections that use TLS are called TLS certificates – this term is interchangeably used with ‘SSL certificates’ due to the term being coined back when SSL was in mainstream use.