What Is TLS and SSL?
What Is TLS and SSL? – Before we get into the topic, lets learn some basics of this topic.
What is SSL, TLS? And how this encryption protocol works?
The SSL protocol and its descendant, TLS, have supplied the encryption and security that has enabled contemporary internet commerce since the dawn of the internet. Continuous modifications have marked the protocols’ decades-long existence, aiming to keep up with more clever adversaries. TLS 1.3, the next major version of the protocol, will be released soon, and most website owners would want to upgrade as soon as possible because fraudsters are catching up.
What is SSL, and how does it work?
When it was first developed in the mid-1990s by Netscape, the firm that made the most popular Web browser at the time, the protocol was known as Secure Sockets Layer, or SSL. SSL 1.0 was never made public, while SSL 2.0 was riddled with faults. SSL 3.0, introduced in 1996, was a thorough overhaul that set the tone for what came after.
[ Not all SSL certificates are the same. What do the various certificates actually mean? | Sign up for our newsletters to stay up to date on all things CSO.
SSL vs. TLS
When the protocol’s following version was released in 1999, the Internet Engineering Task Force (IETF) standardized it and gave it a new name: Transport Layer Security, or TLS. “The differences between this protocol and SSL 3.0 are not striking,” according to the TLS specification. As a result, it’s not truly a case of TLS vs. SSL; rather, the two are generally grouped as SSL/TLS because they create a constantly updated sequence of protocols.
The TLS protocol encrypts all sorts of internet traffic. The most common is web traffic; if the URL in your address starts with “HTTPS,” and there’s a padlock icon indicating that the connection is secure, as shown in this snapshot from Chrome:
TLS, on the other hand, can be utilized in a variety of applications, including e-mail and USENET.
How does SSL work?
To communicate securely over the internet, encryption is required: if your data is not encrypted, anyone can inspect your packets and read confidential information. Asymmetrical cryptography is the safest technique of encryption; it requires two cryptographic keys — pieces of information, usually very large integers — to work effectively, one public and one private. The math is complicated, but in essence, you can encrypt data with the public key, but you’ll need the private key to decrypt it. The two keys are linked by a complicated mathematical formula that is impossible to decipher via brute force. Consider the public key to be the address of a locked mailbox with a slot on the front, and the private key to be the key that opens the mailbox. Anyone who knows where the mailbox is can leave a message in it, but only the private key allows others to view it.
Because asymmetrical cryptography involves such challenging mathematical issues, it necessitates a significant amount of processing resources, to the point where using it to encrypt all of the data in a communications session might bring your computer and connection to a standstill. TLS gets around this difficulty by only employing asymmetrical cryptography to encrypt the discussion at the beginning of the session. The server and client must agree on a single session key that they will both use to encrypt their packets from that point forward. Symmetrical cryptography is a type of encryption that uses a common key and is substantially less computationally costly than asymmetric cryptography. The communication session as a whole is substantially more secure than it would be otherwise because that session key was established using asymmetrical cryptography.
Because it’s the time when the two communicating computers identify themselves to one other, the process by which that session key is agreed upon is termed a handshake, and it’s at the heart of the TLS protocol.
Handshake with SSL
The handshake is quite complicated, and the protocol allows for a lot of modifications. The steps that follow provide a general overview of how it works.
The client sends a secure connection request to the server. The server responds with a list of cipher suites (algorithmic toolkits for establishing secure connections) that it is familiar with. The client compares this to its own list of supported cipher suites, chooses one, and informs the server that it will be used by both of them.
After that, the server presents its digital certificate, which is an electronic document issued by a third-party authority that verifies the server’s identity. We’ll go into digital certificates in greater depth later, but for now, the most important thing to remember is that they include the server’s public cryptographic key. When a client obtains a certificate, he or she verifies its legitimacy.
The client and server create a session key using the server’s public key, which they will both use to encrypt communication for the rest of the session. There are various methods for accomplishing this. The client can encrypt a random number using the public key, which is then given to the server to decrypt, and both sides use that number to establish the session key. Alternatively, the two parties can establish the session key using a Diffie–Hellman key exchange.
This SSL.com page contains a wonderful diagram that shows each communication phase in the TLS handshake procedure.
The session key is only valid for the duration of a single, uninterrupted communications session, as its name implies. If communication between the client and the server is interrupted for any reason — such as a network problem or the client being idle for too long — a fresh handshake will be necessary to establish a new session key when communication is resumed.
What is the difference between an SSL certificate and a digital certificate?
Let’s return to the SSL certificate concept. These certificates are at the heart of the SSL/TLS system, as described in the previous section: they supply the client with the public cryptographic key required to begin secure connections. However, their role extends beyond simply distributing the key; they also verify that the key is indeed associated with the company that is providing it to the client.
What is the mechanism behind this?
Certificates are issued by Certificate Authorities (CAs), which function similarly to a passport office in terms of verifying identities. Organizations that want to provide TLS-encrypted services must buy certificates from CAs, who then verify that the organizations are who they say they are. For example, if you wanted to get a certificate to secure a website at example.com, you’d have to show the CA that you own the domain name example.com. If someone goes to example.com and receives a valid SSL certificate from a trustworthy CA, they can be certain that they’re dealing with the legitimate owner of the domain. As a result, man-in-the-middle attacks can be avoided.
In the last paragraph, you’ll notice that we used the word “trusted CA.” Anyone can start up shop as a certificate authority; how do you know which ones do the necessary due diligence to authenticate their clients? Fortunately, software developers are mostly responsible for figuring this out. The Mozilla Foundation keeps track of which CAs Firefox will trust, and Apple and Microsoft keep track of which CAs they implement at the OS level for Windows, macOS, and iOS, which Chrome uses on those systems. As a 2017 fight between Google and Symantec over what Google perceived to be Symantec’s inadequate standards shown, choosing which CAs to trust has high consequences.
The X.509 standard is used to define SSL certificates. This standard permits certificates to convey a lot more information than simply the public key and the proven identity of the certificate owner; DigiCert provides a full analysis of the standard in its knowledge base.
When you communicate with servers that offer TLS-encrypted connections, almost all of the aforementioned information is exchanged and confirmed behind the scenes. You can use an SSL checker website to acquire a bit more transparency by entering the URL of an SSL/TLS-encrypted site. The checker will return a variety of details about the certificate used by the tested site, including the server type, which web browsers will and will not trust, the issuer, the serial number, and the expiration date.
Most SSL checkers are free services provided by CAS as marketing tools for their products; for example, many will allow you to set an alert for when an examined certificate expires, assuming that it’s your certificate and you’ll be looking for a new one as the expiration date approaches. If you’re looking for a less commercial option, try Qualys SSL Labs’ SSL checker, which delivers a very comprehensive collection of information about inspected websites.
TLS 1.2 and TLS 1.2 vulnerabilities
TLS 1.2 has been the most recently defined version of the protocol for some years. It established a slew of new cryptographic communication options. However, it, like previous versions of the protocol, allowed for the use of outdated cryptographic algorithms to accommodate older systems. Unfortunately, this exposed it to vulnerabilities, as earlier techniques became more vulnerable as time passed and processing power became more affordable.
TLS 1.2, in particular, has become increasingly vulnerable to “man-in-the-middle” attacks, in which a hacker intercepts packets in the middle of transmission and reads or modifies them before sending them on. It’s also vulnerable to assaults like POODLE, SLOTH, and DROWN. Many of these issues have surfaced in the last two years, highlighting the need to update the protocol.
TLS 1.3 (Transport Layer Security)
Fortunately, assistance is on its way. Version 1.3 of the TLS protocol, which is presently in a draught but will be finished soon, closes many of these gaps by removing support for obsolete encryption technologies. There is backward compatibility in the sense that if one end of a connection isn’t capable of using the newer encryption systems on the 1.3 approved list, the connection will fall back to TLS 1.2. A man-in-the-middle attack, for example, attempting to force a fallback to 1.2 to snoop on packets, will be identified and the connection will be disconnected.
There are still servers out there that use TLS versions older than 1.2, and some that use the original SSL protocol. If your server is one of these, you should upgrade right away to the draught 1.3 specifications.
TLS is a type of malware.
One more remark on TLS and security: it’s not just the good people who use it! TLS is frequently used by cybercriminals to encrypt command-and-control traffic between their servers and malware on their victims’ PCs. As a result, the normal state of affairs is inverted, and cybercrime victims are left hunting for a way to decrypt traffic. There are a variety of strategies for dealing with this type of encrypted attack, including leveraging network metadata about the encrypted traffic to obtain a sense of what the attackers are up to without having to read any of it.