What is SSL? Understanding the History of SSL and How it Works

Before diving into the many benefits and uses of SSL Certificates, it may help understand the underpinning technology. This article provides a brief history lesson on how Secure Socket Layer (SSL) has evolved into Transport Layer Security (TLS) and a simple explanation of how they provide security for both Public Internet and Enterprise Intranet connections.

In particular, the aim is to give you a complete overview of the Secure Socket Layer (SSL) protocol and certificates to help you make the best decisions regarding certificate management for your enterprise.

SSL is the original name of the cryptographic protocol for authenticating and encrypting communications over a network. Officially, SSL was replaced by an updated protocol called TLS some time ago. 

The following is a timeline of how SSL has changed over time: 

1. SSL is a security protocol developed by Netscape in the 90s for encrypting and securing communications over the internet. SSL v1.0 was never released due to security issues. 
2. In 1995, Netscape released SSL v2.0, but it still had many flaws. 
3. SSL v3.0 released in 1996 and addressed the problems of SSL v2.0. This version offered incredible improvements and forever changed the way the internet works. However, as of 2015, SSL 3.0 and prior versions have been deprecated. 
4. TLS  was developed by the Internet Engineering Task Force (IETF) as an improvement on SSL; TLS v1.0 released in 1999 and based on SSL v3.0, with minor security improvements still significant enough that SSL v3.0 and TLS v1.0 did not interoperate. 
5. TLS v1.1 came out seven years later in 2006 and was replaced by TLS v1.2 shortly afterward, in 2008. That hurt TLS v1.1 adoption as many websites upgraded from TLS v1.0 directly to TLS v1.2. 11 years later, we are now at TLS v1.3. 
6. TLS v1.3 finalized in 2018 and after nearly 30 IETF drafts. TLS v1.3 makes significant improvements over its predecessors. Microsoft, Apple, Google, Mozilla, Cloudflare, and Cisco all have deprecated TLS v1.0 and TLS v1.1 as of March 2020. TLS v1.2 and TLS v1.3 are now the only SSL protocols still available.  

So, in reality, TLS is simply a newer version of SSL. However, most people still say SSL instead of TLS. SSL and TLS serve the same purpose, protecting sensitive information during transmission, but under the hood, the cryptography has changed a lot from the original SSL to the latest TLS v1.3.  

Digital certificates are the core of the SSL protocol; they initiate the secure connections between servers (e.g., websites, intranets, or VPN) and clients(e.g., web browsers, applications, or email clients).

SSL certificates offer adequate protection against phishing and eavesdropping of transmissions and automatic authentication of a server, such as a website domain. If a website asks for users’ sensitive information, it needs to have an SSL certificate to encrypt it during transmission. If there is no SSL certificate, then that connection should not be trusted with any private information.

The primary purpose of SSL is to provide a secure transport-layer connection between two endpoints, the server and the client. This connection is typically between a website server and the client’s browser, or a mail server and the client’s email application, such as Outlook. 

SSL comprises two separate protocols: 

1. The Handshake protocol authenticates the server(and optionally the client), negotiates crypto suites, and generates the shared key. 
2. The Record protocol isolates each connection and uses the shared key to secure communications for the remainder of the session. 

The SSL handshake is an asymmetric cryptography process for establishing a secure channel for server and client to communicate — HTTPS connections always begins with the SSL handshake.  

A successful handshake takes place behind the client’s browser or application, instantly and automatically — without disturbing the client user experience. However, A failed handshake triggers the termination of the connection, usually preceded by an alert message in the client’s browser. 

Provided the SSL is valid and correct, the handshake offers the following security benefits: 

• Authentication: The server is always authenticated for as long as the connection is valid. 
• Confidentiality: Data sent via SSL is encrypted and only visible to the server and client. 

• Integrity: Digital Certificate Signatures ensure the data has not been modified during the transfer. 

In summary, SSL certificates fundamentally work using a blend of asymmetric cryptography and symmetric cryptography for communications over the internet. There are also other infrastructures involved in achieving SSL communication in enterprises, known as Public Key Infrastructures.

When you receive the SSL certificate, you install it on your server. You can install an Intermediate certificate that establishes your SSL certificate’s credibility by chaining it to your CA’s root certificate.

Root certificates are self-signed and form the basis of an X.509-based Public-Key Infrastructure (PKI). The PKI supporting HTTPS for secure web browsing and electronic signature schemes depends on root certificates. In other applications of X.509 certificates, a hierarchy of certificates certifies a certificate’s issuance validity. This hierarchy is called a certificate “Chain of Trust.”

The Chain of Trust refers to your SSL certificate and its link to a trusted certificate authority. For an SSL certificate to be trusted, it must trace back to a trusted root CA. A Chain of Trust ensures privacy, trust, and security for all parties involved.

At the core of every PKI is the root CA; it serves as the trusted source of integrity for the entire system. The root certificate authority signs an SSL certificate, thus starting the Chain of Trust. If the root CA is publicly trusted, then any valid CA certificate chained to it is trusted by all major internet browsers and operating systems.

The client or browser inherently knows the Public-Keys of a handful of trusted CAs and uses these keys to verify the server’s SSL certificate. The client repeats the verification process recursively with each certificate in the Trust Chain until tracing it back to the beginning, the root CA.

In unsecured HTTP connections, hackers can easily intercept messages between client and server and read them in plain text. Encrypted connections scramble communication until the client can decrypt it with the other session key.

When installed on a web server, SSL certificates use a public/private key pair system to initiate the HTTPS protocol and enable secured connections for users and clients to connect.

When a signed SSL certificate secures a website, it proves that the organization has verified and authenticated its identity with the trusted third party; since the browser trusts the CA, the browser now trusts that organization’s identity too.

The easiest way to check if the website has an SSL installed is to look at your browser; see if the website URL starts with “HTTPS:” as this shows if it has an SSL certificate installed on the server. If so, click the padlock icon in the address bar to view the certificate information.

Web browsers use HyperText Transfer Protocol (HTTP) to connect to web servers that listen on TCP port 80 by default. HTTP is a plain-text protocol, which means it is relatively easy for a hacker to intercept and read the transit data. It is not adequate for any application that requires confidentiality.

SSL uses port number 443, encrypting data exchanged between the browser and the server and authenticating the user. Therefore, when the communications between the web browser and server need to be secure, the browser automatically switches to SSL — that is, as long as the server has an SSL certificate installed.

Establishing a connection with a server with a certificate signed by a trusted CA takes place without additional difficulties for the user. When an internet user visits an SSL-secured website, they are more willing to submit their contact information or shop with their credit card. Furthermore, having an SSL certificate on your website increases your ranking position, making it easier for users and customers to find your site.

SSL certificate attests to the reliability of a website, but with more advanced certificates, the entire company can be SSL certified.

Although SSL’s original purpose was for the World Wide Web, enterprises use SSL certificates to secure a wide variety of internal and external connections. The most common use cases for Enterprise SSL certificates include:

• Network Access controls
• Virtual Private Networks (VPN)
• Single sign-on
• Internet of Things(IoT)

If properly configured, all these applications run atop of SSL protocol. We’ll take a closer look at these examples in the following section:

Employees who connect wireless devices to the corporate network have a need for ease of access, while at the same time, the network must prevent unauthorized access to corporate resources. Employees may use SSL certificates to access and encrypt files from their devices, corporate servers, or even cloud servers for approved individuals.

Avoid the need to remember/reset long, difficult to remember passwords that change every 90 days by replacing it with a digital identity. Place a digital identity into the Windows or Mac desktop, server, or WiFi access points, so only authorized devices can connect to your corporate network.

Today’s enterprise employees have access to a wide variety of Identity service or federation products. Enterprises often use a Web Single Sign-on product to access all its resources in the corporate portal or cloud services.

A digital identity can be installed in your IoT device and the user’s device or application to ensure that only trusted IoT devices could connect to your network. The IoT device takes instructions from or sends data to authorized applications, and users possess a digital identity.

A Secure Sockets Layer Virtual Private Network (SSL VPN) is a virtual private network (VPN) created using the Secure Sockets Layer (SSL) IT departments can scale both the solution and its required infrastructure services. SSL VPN enables granular control over managed application access to enterprise web applications. Perhaps the most significant benefits of SSL VPN come from the gained efficiency and productivity of freeing up IT resources by enabling all digital certificates to be accessed remotely.

Many people don’t realize that code, document, and email signing certificates are not SSL certificates. Even though they are all facilitated by PKI x.509 certificates, the key-usage function makes all the difference. Read “Difference Between Code Signing and SSL certificate” or “Difference Between Digital certificate and Digital Signature” to learn more on the subject.