What Is HTTPS, and Why Should I Care?
For better or worse, Google has been the leader of many changes and developments into how developers build, host, and fill websites with content.
For better or worse, Google has been the leader of many changes and developments into how developers build, host, and fill websites with content. HTTPS is one of their latest areas of interest, and no matter what kind of website you host from your VPS, you should care about how HTTPS works and why it’s necessary.
It’s July 2018, and Google’s Chrome version 68 is almost here. With this version, Chrome will start flagging all the websites that operate on HTTP as insecure. Even before this, Chrome actively marked sites which used HTTP and had forms where users can input data as insecure, leading to concerned users and frustrated business owners.
But now Google is getting stricter than that. If your site doesn’t have HTTPS enabled, you run into the trouble of losing SEO ranking due to being marked as insecure in the URL bar. All your content marketing and keyword targeting efforts could disappear overnight if Google starts to de-prioritize your content, thus not showing it to nearly as many people. Your users might even begin to look elsewhere.
If there was ever a time for people to start taking HTTPS seriously, it’s right now.
SSL, TLS, and TLS versions
HTTPS is HTTP with TLS, where TLS stands for “Transport Layer Security.” Often TLS and SSL are used interchangeably in this context, but the fact of the matter is that SSL is the predecessor of TLS. Currently, most websites are using TLS version 1.2 and transitioning towards version 1.3 with older versions supported as well.
Now that we have the acronyms and versioning sorted let’s ask the critical question here.
What is HTTPS?
Data flows over the internet through a wide range of interconnected servers, some state-sponsored, and some maintained by corporations. Others could even be set up by malicious entities. Even if your web server is secure, there is no guarantee that the data it sends to a client, over this network of untrusted entities, will not get intercepted by some third-party along the way. Often this is termed as the “man-in-the-middle” attack (MITM).
HTTPS attempts to solve this and many other problems by establishing an encrypted channel between the client (the web browser) and the server. Encryption upholds the fundamental principles of data security to a reasonable degree of certainty. These principles are:
Data integrity: Ensuring that the data received was not tampered by any uninvited guest who intercepted it as it was on its way.
Privacy: Even if someone decides not to modify the data, but merely listen in on it or make a copy of the traffic as it flows through, that would violate the user’s privacy. In principle, if the server uses HTTPS, this third party won’t be able to make any sense of the data because the data is encrypted (scrambled) and only the trusted parties have the key (think of it as a password) to decrypt (unscramble) it.
Authenticity: Authenticity implies that websites are what they claim to be. If you visit https://www.datamounts.com, the HTTPS certificates that it comes with help your browser verify that it is indeed the website for Data Mounts and not a third party just claiming to be DataMounts.com.
The first two principles are upheld by the cryptographic techniques that the OpenSSL/LibreSSL libraries implement in most browsers and web servers. But we have a lot to say still on the point of authenticity.
Authenticity via HTTPS
The most vulnerable aspect of secure communication is the first step involved in establishing it. For instance, when Alice visits https://example.com for the first time, it has to send encrypted content and the keys necessary to decrypt that content over an insecure channel. How else can the communication begin? Since Alice’s browser doesn’t have the right keys for example.com yet, they need to be sent over unencrypted.
But if there’s a MitM attack in this very crucial first exchange, how can anything else from that point onwards be trusted?
Someone else can stand in between Alice and example.com, completely obstruct that website’s original content, and serve malicious contents instead. Sure, the malicious content can also be encrypted and secured with a key, a different key, but a key nonetheless.
For all intents and purposes, that malicious website is all that would exist for Alice. This malicious server deceives her for the entirety of her session! You could see how this would be bad for Alice if the malicious server pretended to be her online banking dashboard or a favorite retailer that’s asking for her credit card information.
The way we work around this trust issue is through the use of certificates and a Certificate Authority.
Digital certificates work pretty much like real-life ones. They can be used to prove your authenticity. The internal mechanism of how a certificate helps establish your identity is beyond the scope of this post, but let’s first paint a picture with broad brushstrokes.
Certificate authorities and HTTPS
The certificate authority is a party that everyone on the Internet has decided to trust. Your browser, and even your operating system, comes with a baked-in knowledge of the existence of a list of certificate authorities (CAs). You can never visit a CA for “the first time,” even on a brand new device, because every major OS vendor and every browser like Chrome, Firefox, Edge, or Safari know precisely what certificates the CA itself would use, and thus they can’t be cheated by a third party.
Once we have this first step of having trusted CAs, we can use them to prove our own website’s trustworthiness. When you request a certificate for your DOMAIN.TLD, the CA asks you to perform a certain set of challenge(s). It may ask you to setup a DNS record which you can do only if you own that domain name, or make a unique string available at its web root http://DOMAIN.TLD/special_resource to prove to the CA that the domain name points to the correct web server. Once that is done successfully, the CA issues a TLS certificate to the web server. Now, if a browser tries to visit this website and sees it offering an HTTPS certificate, the browser can check against all the CAs and verify that one of them has indeed issued that specific certificate to your domain name.
Failing that, the browser warns its user that the website might not be what it appears to be—often stated as “Deceptive Site Ahead” warning.
LetsEncrypt and CloudFlare
A few years back, TLS certificates were paid commodities. You incurred additional costs on top of your VPS subscription and domain name subscription by paying a Certificate Authority for the TLS certificate. You needed to continue your subscription, because certificates are expected to expire after a specific time due to security concerns.
Let’s Encrypt, a free Certificate Authority dedicated to making the Internet a more secure and privacy-respecting space, has changed this situation dramatically. Another significant player in the CA space is CloudFlare, which many of us already know as a CDN service provider.
Both organizations offer free TLS encryption, with which you can secure your website and user data. Browsers then display a green padlock icon in the URL bar to “prove” to the user that it’s an encrypted connection backed by a CA.
Which one should you use? Using Let’s Encrypt could be technically demanding. You need to know all about certificate renewal, configuring web servers like Nginx to use the certificates, redirect HTTP requests to HTTPS, and so forth. On a VPS with SSH/shell access, you will have to use tools like Certbot (more on this in a moment) for obtaining certificates, although Certbot does make this process quite easy.
Whereas if you’re using CloudFlare, you can have a nice GUI to enable SSL (TLS) within minutes. You may still have to worry about certificate renewal if you go with a Full Strict policy, which offers you a certificate-key pair to add to your server. If you want encrypted communication between just the CloudFlare DNS service and the clients visiting your site, you go with a Flexible policy instead. For starters, you can stick to the latter—it gets you the green padlock in browsers and is reasonably secure.
CloudFlare offers four different kinds of SSL setups, but that’s a story for another day.
Certbot for LetsEncrypt
Certbot is the most popular software to automate the process of installing TLS certificates and renewing them. It works best with Let’s Encrypt as the Certificate Authority, but it can work with any CA that supports the ACME protocol. That’s a system used to prove to a CA that you control a domain name and can rightfully demand certificates for it.
In any case, the Certbot site can help you install certificates and make them work with popular web servers like Apache, Nginx, and so on, without knowing everything about ACME protocol and various other technicalities. You may also be interested in the Caddy web server, which automatically integrates with Let’s Encrypt.
That means you don’t have to worry about modifying Nginx or Apache2 config files ever again. What a relief.
Summary
Between Google’s incoming changes and a greater emphasis on security/privacy among consumers, you should be using HTTPS. If you’re not comfortable with Linux administration, use the free plan from CloudFlare to maintain your DNS records, and you can get SSL certificates free of charge. Want use Docker containers and have a full-blown application stack with multiple sites?
Everything, from static web pages to e-commerce websites, needs SSL. Encryption is helpful not just for your business, but also for the visitors to your website, and the Internet in general. And there has never been a better time than right now to adopt the encrypted future of the web.