SSL (Secure Sockets Layer) is a networking protocol that secures connections between web clients and web servers over internal networks or the internet by encrypting the data sent between those clients and servers.

Why is SSL important?

Part of SSL's significance lies in the fact that it was the first widely used and broadly implemented network protocol to enable cryptographically secured communications between client and server systems. SSL uses public key and private key encryption and other cryptographic functions to secure connections between devices communicating over a TCP/IP network. SSL can scramble clear text (plaintext) entered on a website using asymmetric cryptography and public key encryption. It is just one of the ways in which public key infrastructure (PKI) is used by modern businesses.

SSL was mainly used to secure connections between web clients and web servers to secure communications between them and to ensure their privacy. Without SSL, data sent to and from a website could be intercepted and easily read.

Authentication is another important use of SSL. By authenticating two communicating devices, SSL confirms that the devices are what they claim to be, thus ensuring data and communications integrity. As such, SSL facilitates safe transactions between consumers and businesses, which helped to set the foundation for e-commerce.

In addition to securing internet connections, SSL is also used to authenticate and encrypt applications at the network transport layer of the Open Systems Interconnection model. The protocol's location between the application layer and the TCP/IP layer ensures that application data is securely sent to the transport layer, while also allowing client and server applications to detect security risks, like communication tampering, forgery or interception.

Why is SSL used?

SSL became a key part of internet security because of problems with HTTP, the framework used to connect web clients to web servers. HTTP uses public networks and lacks encryption, making it vulnerable to many kinds of cyberattacks. Malicious actors can easily read or extract names, addresses, credit card numbers and other personally identifiable information sent to a website using HTTP.

To address these weaknesses, HTTP over SSL (HTTPS), also known as HTTP Secure, has emerged as HTTP's more secure successor. Most websites today display the prefix HTTPS at the beginning of their web address. The "s" indicates to the visitor that the site uses SSL -- or, more commonly, its more secure successor, Transport Layer Security (TLS) -- to secure communications, encrypt data, facilitate authentication and maintain user privacy. The use of HTTPS is particularly common with websites related to banking, e-commerce and other types of financial transactions.

Steps involved in the SSL process

To understand the steps involved in the SSL process, consider the procedures implemented by an e-commerce company called Brand A:

1. Initial connection. When a customer logs on to Brand A's website, the user's web browser indicates to Brand A's server that the user wants to establish a private connection. This initial communication, known as a handshake, starts when the user's browser first queries the website's origin server. After receiving this notification from the browser, Brand A's web server sends over its SSL certificate, which includes its public key.
2. Certificate authentication. As part of the initial handshake process, Brand A's server presents its SSL certificate to authenticate itself to the client. In this case, that is the customer's web browser. Server certificates follow the X.509 certificate format defined by Public-Key Cryptography Standards. The web browser analyzes the certificate to verify that the customer is interacting with the intended server. Public key encryption is used to validate the digital certificate and to verify that a server is what it claims to be. Most web browsers implicitly trust SSL certificates that have been issued by a certificate authority (CA) as a way of expediting the process.
3. Message encryption. Once the browser, or client, has authenticated the web server and its certificate, it encrypts the user's message using Brand A's public key. The message is then sent to Brand A's server.
4. Message decryption. Brand A's server decrypts the message using its own private key. The message includes a symmetric session key to establish a two-way handshake between the two entities.
5. Cipher settings and shared encryption key. Once the server has been authenticated, the client and Brand A's server establish cipher settings and a shared key to encrypt the information they exchange during the remainder of the session. This provides data confidentiality and integrity, and the process is invisible to the customer. For example, if a webpage requires an SSL connection, the URL changes from HTTP to HTTPS, and a padlock icon appears in the browser once the server has been authenticated.
6. Client authentication. The handshake also allows the client to authenticate itself to the server. In this case, after server authentication is complete, the client must present its certificate to the server to authenticate the client's identity before the encrypted SSL session can be established.

Importance of SSL certificates

For a company to implement the SSL protocol on its website, the process starts with acquiring a valid SSL certificate from a trusted CA. The purpose of the SSL certificate is to inform the user and their web browser that they are interacting with the desired web server and not an imposter.

Suppose Brand A wants to launch a secure website where users can safely order its products without the risk of having their sensitive information, such as credit card numbers, stolen by hackers or cybercriminals. To secure its site, Brand A uses SSL on the website by coordinating with a reputable CA and getting an SSL certificate from the CA.

The SSL certificate, which is a specific type of digital certificate, includes the following information:

• Person, organization or device to whom the certificate was issued -- in this case, Brand A.
• Certificate thumbprint, which is a hash of all the certificate data and its signature.
• SSL or TLS version being used.
• Domain name it was issued under, e.g., www.brandA.com.
• Any associated subdomains.
• Name of the issuing CA.
• CA's digital signature.
• Certificate's issue and expiration dates.
• Public key -- available to any user.
• Associated private key that is kept secret.

The certificate confirms to Brand A's customers that Brand A owns its specified domain where it is conducting e-commerce transactions. It also verifies Brand A's reputation by referencing the SSL certificate's CA details. This lets the customer and their web browser know that the site can be trusted and that they can safely conduct their transactions without fear of their information or identity being stolen. Websites that are secured with SSL -- or its successor, TLS -- usually display a lock symbol next to the web domain. Search engines rank these sites higher on their results pages based on the additional user security.

Types of SSL certificates

There are three main types of SSL certificates that companies can obtain from a CA. These are Extended Validation (EV SSL), Organization Validation (OV SSL) and Domain Validation (DV SSL). The encryption levels are the same for all three types, but the processes used to verify applicants for the certificates differs:

1. EV SSL verifies the existence and identity of the entity making the application and its right to use the domain it is applying under. A range of supplemental documents, as well as background checks, are required to get EV SSL. It can take five or more business days to get this certificate.
2. OV SSL verifies the right of the applicant to use the domain and does some vetting of the organization. It can take two to five days to obtain.
3. DV SSL verifies the person submitting the certificate request. Company information is not checked. It requires only email or internet confirmation of the request. It can be obtained in a few hours.

SSL and public/private keys

PKI for cryptography is an important element of the SSL protocol. The public and private security keys used are unique and mathematically related. Also, the use of these two keys makes this cryptographic method asymmetric. The information sent from one device to another is encoded using the public key to prevent it from being intercepted or read by unauthorized parties, like hackers. Simply put, the public key and the private key act as the encryptor and the decryptor, respectively. Essentially, the system acts like a door that can only be locked with a public key and unlocked with a private key.

To decode the encrypted information, the receiving device needs the private key. Without this key, the information encrypted using the public key cannot be decoded. The private key can only decrypt data that has been encrypted by the public key. The public key gets its name because it is distributed publicly. However, its utility is negligible without access to the private key. The private key is kept secret by the web server associated with a particular website in order to secure communications between the web server and various web clients.

SSL vs. TLS

SSL was originally specified in the 1990s as a proprietary protocol that enabled Netscape browser clients using HTTP to communicate securely with Netscape web servers. While version 1.0 of SSL was never released, version 2.0 made its debut in 1995. The Internet Engineering Task Force took over the SSL protocol to standardize it through an open process. Version 3.1 of SSL was released as TLS 1.0. The name was changed to avoid potential legal issues with Netscape.

While TLS and SSL are not interoperable, versions of TLS through 1.2 were backward-compatible with SSL 3.0. However, backward compatibility with SSL was removed from TLS 1.3, the current version of TLS that was published in 2018.

Many attacks against SSL have focused on SSL implementation issues. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability is a known flaw in the SSL 3.0 protocol itself. POODLE exploits the way in which SSL ignores padding bytes when running in cipher block chaining mode. This flaw allows an attacker to decrypt sensitive information, such as authentication cookies. TLS 1.0 is not vulnerable to this attack because it specifies that all padding bytes must have the same value and must be verified.

Other key differences between SSL and TLS that make TLS a more secure and efficient protocol are message authentication, key material generation and supported cipher suites, with TLS supporting newer and more secure algorithms.

SSL and TLS are just one part of the bigger network security picture. Find out more about network security in our ultimate guide to the zero-trust security model.