[ ssl ] [ https ] [ http/2 ] [ security ] [ certificates ] [ Let's Encrypt ] [ Networking ]
Contents
WHAT IS SSL?
SSL is short for Secure Sockets Layer and provides a means to communicate securely from one device to another. The website server is identified by a certificate and uses a public and private key to create a secure connection between the client and server.
HISTORY OF SSL
Netscape developed the original SSL protocols.[6] Version 1.0 was never publicly released because of serious security flaws in the protocol; version 2.0, released in February 1995, “contained a number of security flaws which ultimately led to the design of SSL version 3.0”.[7] Released in 1996, SSL version 3.0 represented a complete redesign of the protocol produced by Paul Kocher working with Netscape engineers Phil Karlton and Alan Freier, with a reference implementation by Christopher Allen and Tim Dierks of Consensus Development. Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historical document in RFC 6101.
Dr. Taher Elgamal, chief scientist at Netscape Communications from 1995 to 1998, is recognized as the “father of SSL”.[8][9]
Source: Wikipedia
WHY SSL IS IMPORTANT
As an end user you should care about keeping your data private. Sensitive information (e.g., login credentials or credit card numbers) should only be submitted via secure web pages. The prevalence of wireless networks makes SSL even more important. Wireless networks are notoriously easy to capture data passed between devices.
As a website administrator you should care about providing your users with a secure experience. In addition to protecting people’s privacy you can also expect to receive a minor boost to your page rank from Google.
The goals of SSL/HTTPS are to provide a secure channel of communication. You should be able to trust that the SSL certificate you receive was actually issued to the website you are visiting and that it is non-trivial for a third party to read the data passing between the client and server.
WHAT ARE CERTIFICATES?
The identifying SSL certificates are signed by a root certificate authority using the authority’s intermediate certificate and the intermediate certificate is signed by the authority’s root certificate. This produces a certificate chain. This certificate chain contains every certificate issued starting with the server certificate and linked back up to the root authority’s root certificate.
CERTIFICATE CHAINS
At the time of this writing blue42 is secured using a free certificate from Let’s Encrypt. The have published visual representation of the relationship between their certificates. Below is their image and the certificate chain for blue42.net as produced by the command openssl s_client -connect blue42.net:443.
---
Certificate chain
0 s:/CN=blue42.net
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
You can see from the command output that my server certificate was issued by Let’s Encrypt Authority X3 whose certificate was issued by DST Root CA X3 which can be visualized using their diagram.
Certificate chain information can be viewed on any website using SSL with the openssl command specified above or the Qualys SSLTest website.
TYPES OF CERTIFICATES
There are a few different types of certificates that can be used to secure a website. Single domain certificates (e.g, www.blue42.net) secure only a single host name – usually www and the domain name itself. These type’s of certificates tend to be the cheapest and in some cases (Let’s Encrypt) free.
Suppose you have three websites you want to secure. Instead of managing multiple single domain certificates you can purchase a UC/SAN (unified communications) multi-domain certificate. These certificates will list many domains (SAN - Subject Alternative Name) and allows you to host multiple secure sites on a single IP address.
Another common type of certificate is a wild card certificate. A wild card certificate will typically list *.domainname.com as the common name. This allows the certificate to be used on any host name belonging to the parent domain (e.g, ssl.blue42.net, www.blue42.net, mail.blue42.net, etc).
The last major type of certificate is an extended validation or EV certificate. This type of certificate is supposed to identify and validate the entity that purchased the certificate as the proper owner of a domain. This gets you a fancier green lock that includes the organization name in the address bar.
PROTOCOLS & CIPHER SUITES
PROTOCOLS
SSL protocols are known by two names. The earlier protocols were called SSLv1.0, SSLv2.0, and SSLv3.0. The newer protocols are TLSv1.0, TLSv1.1, and TLSv1.2. All new browser versions support TLSv1.1 and TLSv1.2. However, if you need to support older browsers such as Internet Explorer on Windows XP you will need to use SSLv3.0 also.
You should stick with TLS and be selective about which cipher suites you choose.
CIPHER SUITES
Cipher Suites (Wikipedia) define the encryption algorithm, key exchange, message authentication code and pseudorandom function used in an SSL connection.
This is important because some encryption algorithms are easily broken and make it easier for attackers to impersonate a server or capture your unencrypted data while in transit.
If a flaw is found in one a component of a cipher suite that can cause that suite, or any suite using that component insecure. As a result, it is important to stay informed on which cipher suites are still considered secure and adjust your server configuration appropriately. For example, all RC4 ciphers are considered insecure and should not be used under normal circumstances.
COMMON VULNERABILITIES
There are many SSL vulnerabilities. The details of which are beyond the scope of this post but you can find a good listing on Wikipedia if you’re interested in more reading. It isn’t required to understand the intricacies of the exploits to keep your server secure.
DEPLOYING SSL AND CERTIFICATES
The most important part of deploying SSL securely is to test your configuration. When you test thoroughly you’ll know whether you have any security issues and if you’re required to support older hardware/software you’ll be able to do so in the most secure way possible.
SSLLabs.com is probably the most popular way to test your SSL configuration assuming your server is publicly accessible. It offers great feedback when something is configured insecurely and relevant links when something is configured sub optimally. It will also show you software compatibility information and areas you can improved based on your actual live site.
It used to be that purchasing an SSL certificate was expensive for individuals. The easiest way to deploy a site on SSL is to find a hosting provider that offers free SSL hosting. Many offer free certificates for custom domain names.
However, if you want to setup your own server for whatever reason we’re going to need to get a certificate and configure a web server. I personally use nginx and below is my current SSL configuration. At the time of this writing my server gets an A+ on ssllabs.com.
NGINX CONFIGURATION
# SSL Configuration
ssl on;
ssl_certificate /etc/letsencrypt/live/blue42.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/blue42.net/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 180m;
ssl_session_tickets on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_dhparam /etc/ssl/certs/dhparam.pem;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
ssl_stapling on;
ssl_stapling_verify on;
# END SSL Configuration
Let’s Encrypt is a free way to get SSL certificates. The certificates are currently only valid for a period of three months, but are extremely easy to renew as long as you are running your own server (or using a provider takes care of renewal for you).
In the example above ssl_certificate and ssl_certificate_key tells nginx where on the server filesystem to find the certificate and key file respectively. The ssl_ciphers option is important to tell nginx which ciphers we want to use. This option in conjunction with the ssl_protocol options are the most important to get right when it comes to security.
The add_header Strict-Transport-Security line will tell browsers they should only access this site using SSL. Do not set this option until you have tested your SSL configuration and are ready to move most/all of your traffic to HTTPS.
A description of all SSL options used in the configuration above, and all other SSL options, is available in the nginx documentation.
Conclusion
Hopefully this post helped explain the basic concepts of using SSL on your website. It doesn’t cover everything in detail, but it should give you a good starting point and enough information to start experimenting on your own.
I encourage you to continue reading and taking advantage of other resources available to learn as much as possible about SSL and HTTPS. The Internet is heading to a place where traffic will be encyrpted by default. However, it is important to understand what that means, how secure it really is, and in which areas that “security” isn’t actually secure.