Secure Sockets Layer (SSL) is a protocol for securing communication on the Internet. It provides a way for enterprises to encrypt data before sending it to users, preventing third parties from reading it while it’s in transit.
Every day, millions of users transmit sensitive information over the Internet. From bank statements to social security numbers, transmitting unsecured data can result in a third party intercepting the data, manipulating the data, or using the data for identity theft.
SSL and the superseding Transport Layer Security (TLS) protocols resolve this issue by encrypting data when it leaves a web server and decrypting it when it arrives at its destination. SSL is used for websites, email, remote login, and much more.
SSL works through the use of public key cryptography. Public key cryptography uses two keys – a private key and a public key – to transmit secure data between two systems. These keys are essential to respectively decoding and encoding secure data.
Step-by-step, here’s how SSL works:
Public key cryptography is similar to using a padlock. The padlock itself is the public key and the combination is the private key. The server distributes its padlock, which anyone can use to lock a door or a box. However, the padlock can’t be opened without the combination, which only the server knows.
Say a user wants to access their StackPath account. To ensure security and confidentiality, StackPath forces high-grade encryption across their website. When the user goes to log 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), which are entities entrusted with selling and distributing SSL certificates. CAs form the backbone of SSL, providing new certificates and verification of existing certificates.
The steps for enabling SSL is 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, for a domain with multiple subdomains, or for multiple domains. CAs may also request various levels of validation depending on the type of certificate, from checking the registered owner of the domain 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 email address of the administrator.
When the CA verifies the CSR, they will send the certificate along with 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.
SSL creates trust by providing a secure channel for users to communicate with online services.
In 2012 alone, over 16 million people became victims of identity theft due to improperly protected data. Our dependence on digital communication has made that number more likely to increase unless enterprises take additional steps to secure user data. SSL and TLS are the first line of defense in protecting customers and ultimately the business itself.
Content delivery networks like StackPath make deploying SSL and protecting websites as easy as clicking a button.
