Before diving into the many benefits and uses of SSL Certificates, it may help to understand the underpinning technology. This article provides a brief history lesson on how Secure Socket Layer (SSL) has developed 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.
What is SSL?
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.
SSL to TLS Timeline
The following is a timeline of how SSL has changed over time:
- 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 because of security issues.
- In 1995, Netscape released SSL v2.0, but it still had many flaws.
- SSL v3.0 was 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.
- TLS was developed by the Internet Engineering Task Force (IETF) as an improvement on SSL; TLS v1.0 was 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 inter-operate.
- 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.
- TLS v1.3 was finalized in 2018 after nearly 30 IETF drafts. TLS v1.3 makes significant improvements over its predecessors. Microsoft, Apple, Google, Mozilla, Cloudflare, and Cisco 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 start 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 on transmissions and automatic server authentication, 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 private information.
How does it work?
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, the client’s browser, or a mail server and the client’s email application, such as Outlook.
SSL comprises two separate protocols:
- The Handshake protocol authenticates the server(and optionally the client), negotiates crypto suites, and generates the shared key.
- The Record protocol isolates each connection and uses the shared key to secure communications for the rest of the session.
Handshake Protocol
The SSL handshake is an asymmetric cryptography process for establishing a secure channel for servers and clients to communicate — HTTPS connections always begin with the SSL handshake.
A successful handshake occurs behind the client's browser or application, instantly and automatically — without disturbing the client's 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. Other infrastructures are also involved in achieving SSL communication in enterprises, known as Public Key Infrastructures.
How SSL Certificates Work
- A browser or server attempts to connect to a website (i.e., a web server) secured with SSL. The browser/server requests that the web server identify itself.
- The web server sends the browser/server a copy of its SSL certificate.
- The browser/server checks to see whether or not it trusts the SSL certificate. If so, it sends a message to the web server.
- The web server sends a digitally signed acknowledgment to start an encrypted SSL session.
- Encrypted data is shared between the browser/server and the web server.
There are many benefits to using SSL certificates. Namely, SSL customers can:
- Utilize HTTPS, which elicits a more robust Google ranking.
- Create safer experiences for your customers.
- Build customer trust and improve conversions.
- Protect both customer and internal data.
- Encrypt browser-to-server and server-to-server communication.
- Increase the security of your mobile and cloud apps.
Example of SSL
Say a user wants to access their StackPath account. To ensure security and confidentiality, StackPath forces high-grade encryption across its website. When the user logs in, their browser automatically exchanges keys with StackPath’s servers. These keys are then used to exchange encrypted messages between both systems, preventing anyone from eavesdropping or intercepting sensitive information.
When SSL is enabled on a webpage, the URL will have an “https” prefix instead of an “http” prefix. Most browsers also display a padlock icon or a green bar near the URL, depending on the level of encryption.
SSL certificates are issued through Certificate Authorities (CAs), entities entrusted with selling and distributing SSL certificates. CAs form the backbone of SSL, providing new certificates and verifying existing ones.
Getting started with SSL
The steps for enabling SSL are different for Apache, Nginx, and IIS, but the process is the same. The first step is to choose a CA and the type of certificate. Certificates can be used for a single domain, a domain with multiple subdomains, or multiple domains. CAs may also request various levels of validation depending on the type of certificate, from checking the domain's registered owner to requesting legal identification.
The next step is to generate a private key and the certificate signing request (CSR). CSRs are provided to the CA in exchange for an SSL certificate. CSRs contain information that will be used in the certificate, such as the location of the organization, the domain name, and the administrator's email address.
When the CA verifies the CSR, they will send the certificate and several additional certificates. These additional certificates are known as intermediate certificates and are used to verify the certificate with the CA. (Intermediate certificates stand between the public web and the CA's root certificate, which has to remain private.) Once these certificates are installed, the server is SSL-ready.
Benefits of SSL
SSL creates trust by providing a secure channel for users to communicate with online services.
- Users are more confident in web services since they know their data is transmitted safely.
- Enterprises see higher customer retention and trust since their customers are more confident in their ability to safeguard data.
- Users and enterprises see fewer data theft incidents since sensitive data is no longer at risk of being intercepted.
Thank you for reading this blog.