I spent a lot of time at work this week pair programming with a new member of our team who was hired about a month after I was. It was really great to have an opportunity to share what I’ve learned since starting at a new job, but also to face some challenging questions and to learn from her. We were looking at a client’s site and, on one page, we received a Not secure warning from our browser.
And so, as always, this type of conversation ensued:
Coworker: Weird I wonder why this part of their site is not secure.
Me: Honestly I…don’t know what that means.
Coworker: I know it means that they haven’t paid for an SSL certificate…
The warning wasn’t relevant for the work we were doing, so we didn’t go much deeper than that. But, as always, that little bell went off in my head and I sought to learn more. My quest to learn what exactly was Not secure and how to secure it took me back to some a basic principle of online browsing: HTTP.
HTTP: Sending information over the internet
HTTP, or HyperText Transfer Protocol, is ubiquitous online for a reason — it’s the means by which browsers retrieve the information needed to load a website. A lot of this might be review, but I suggest you bear with me because it’s worth repeating.
The internet is a giant network, and all network communication consists of a series of requests and responses. HTTP is a type of request that is made when we attempt to navigate to a web page. It is made up of:
- HTTP version type
- URL
- HTTP method (GET, POST, etc)
- HTTP request headers
- HTTP body (optional)
To help visualize this, take a look at this example from a really useful Cloudflare article:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: enEven if we don’t understand every part of the request, we can roughly understand that it’s a GET request for a text file from a host called example.com. We would expect the response to this request to be…the text file. And we can do all that because this request is written in plain text.
In fact, all HTTP requests are written in plain text and can be read by third parties at certain network junctions. That doesn’t really matter in this case, but we’re very often sending very private or very sensitive information when we’re making HTTP requests. Every time we fill out a form, like a login or a payment form, we’re sending a POST request to a server. We don’t want that to be intercepted by a malicious third party.
HTTPS
HTTPS can be explained simply: the S stands for security and the protocol uses SSL/TLS to encrypt requests and responses. This transforms those easy-to-read text requests into strings of seemingly random characters like this:
t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==But of course at some point these characters have to be decoded and processed as the attributes mentioned above like request type, URL, and headers. What’s preventing our malicious third party from simply decoding the message once they intercept it?
SSL/TLS
SSL and its descendant, TLS, were developed to prevent increasingly sophisticated attacks and decryption attempts from hackers online. SSL, which stands for Secure Sockets Layer, was developed by Netscape in the mid-1990s. TLS, which stands for Transport Layer Security, was first developed in 1999 and, despite its name, is essentially an update following SSL 3.0. Both protocols are maintained and are often referred to together as simply SSL/TLS. Their jobs are securely encrypting internet traffic.
Data is encrypted by running the characters through a complex mathematical hashing that turns something readable into gibberish. The hashing must be complex so that it’s nearly impossible to decode without context, but it also must be consistent so that we will know how to decode it when we need to. SSL and TSL use keys to hold the values needed for encryption and decryption.
A classic method of encryption, symmetric encryption, involved an algorithm generating a single key shared between a client and server. The key would be used for both encryption and decryption, so there was some security risk because it had to be shared among multiple parties. A more recent alternative, asymmetric encryption, uses a public encryption key, but a private decryption key. Since the decryption key only needs to be held by the request receiver, it’s much safer.
Because of the additional complexity involved in asymmetric encryption, it’s not efficient enough to be used for every single piece of web traffic. Instead, it is commonly used at the start of a communication to encode the value of another key, which is then used for symmetric encryption. So even if that value is shared, it’s been very securely hidden and therefore can’t be cracked.
Where do I sign up?
There’s still a lot more to understand about encryption, but what’s clear by now is that we want it. We’d like to see that the pages we visit are secure so that our browsing habits and data aren’t being stolen by strangers (paying no mind of course to those third parties that we willingly provide that information to when we browse). So how do we as web developers or business owners turn our HTTP requests into HTTPS requests? Buy it!
Fortunately (or unfortunately) for us, the task of encryption has mostly been abstracted through the sale of SSL certificates. There are a ton of vendors out there all eager to encrypt and authenticate your traffic for an annual fee. As to why the client had it missing on that one page of their site…your guess is as good as mine. It was most likely a missed setting or configuration somewhere that will swiftly be corrected but, until then, we can at least understand the implications of submitting information to a page with a warning.
Update!
My good friend Danny Lee pointed out that there are great free options for SSL certification. Let’s Encrypt offers free certificates, as does Netlify if you use a custom domain with their service. Happy hosting!