It’s been a while since I’ve last written, and a lot of that is because I was busy with the last semester of my master’s degree in Software Engineering. Unfortunately, my deep-dive, analysis-driven style of writing with all of the fancy citations takes a lot of time to write, but I still want to write regularly.
Today I want to talk about HTTPS, and how amazing it is. You’ve probably heard of HTTPS by now. If you haven’t, you may know it better as the “padlock” up there near the address bar of your browser. Yes, the infamous padlock icon that vows to keep you, humble internet citizen, safe from cyber threats. Right? Well, maybe it’s a bit more nuanced than that. So consider today “International HTTPS Appreciation Day” because I feel that HTTPS is an amazing protocol that we take for granted every day.
So HTTPS stands for “Hypertext Transfer Protocol Secure.” And now you know why no one calls it by its full name. But as the name implies, it is the “secure” extension of HTTP. To avoid getting caught up in terminology, think of it like this. You have a pen pal who lives across the country and you want to send them a postcard. You write a short message, add their address, apply postage, and send it through the post. Anyone who finds this postcard can see not only where it’s going, but also the message you wrote. This is akin to HTTP. Let’s redo this scenario, but you instead write a letter and seal it in an envelope. Now, if someone found the envelope, they would only be able to see where the letter is going, but not the content of the letter.¹ This is HTTPS, where encryption has taken place on the messages.
But why does everything need to be encrypted? After all, right now, you’re just reading a simple blog post. Certainly, we shouldn’t waste computing power on encrypting this when far more sensitive traffic exists, like banking transactions. Well, that was the general belief for a while until the early 2010s.
In 2010, HTTPS was relatively rare, with many logins using HTTP or requiring an explicit opt-in for HTTPS. Developer Eric Butler was aware of the security vulnerabilities that HTTP connections had. Looking back, I believe that many site owners didn’t see HTTPS as worth the time, money, and speed cost to implement. Butler decided to play devil’s advocate and created a Firefox extension called Firesheep. It introduced “session hijacking” to the masses. This made it easy for anyone to head to their local Starbucks, fire up the extension, and browse a site like Facebook logged in as someone else.²
“Websites have a responsibility to protect the people who depend on their services. They’ve been ignoring this responsibility for too long, and it’s time for everyone to demand a more secure web. My hope is that Firesheep will help the users win.”
Eric Butler
It was Firesheep that pressured web giants to adopt HTTPS. It was a major shift in thinking. Major sites like Twitter would add HTTPS support in the coming months³, with many more sites to join. HTTPS ended up being very close to HTTP in terms of performance, especially considering the massive benefit of encryption. The secure protocol would be made both easier and free to implement with the founding of Let’s Encrypt, which this blog uses for its encryption.⁴ Whereas once HTTP was seen as standard, it would only be a few years before most web browsers would mark all HTTP connections as “Not Secure.”⁵
I also believe that there is a sense of neutrality when everything is encrypted. Your device is constantly making requests to servers. Some of it is privacy-critical, like emails and messages, while others aren’t, like weather information or the news. If we only encrypted the privacy-critical requests and responses, a bad actor would immediately know which requests have sensitive information, even if they aren’t able to crack the encryption. When everything is encrypted, it’s not even worth a bad actor’s time to figure out which requests have private information.
It’s also worth noting that what most would consider “not privacy-critical” information can be used against us fairly easily. For example, weather reports can implicitly tell someone your general location.
There’s one thing I don’t like about HTTPS, and it has nothing to do with the protocol itself. Rather, it’s about how it’s communicated to the public. When cautioning the public about scams and malicious websites, banks and security experts will often say to look for the padlock indicating HTTPS. Yes, this is a good thing to do, because no reputable company would use regular HTTP today, however it could give the impression to the average person that the padlock indicates reputability, which is not true. Look at my website. It has the padlock. And while I have no malicious intentions, it doesn’t change the fact that I’m just a random person on the internet. Pretty much anyone can host their site with HTTPS. I’ve seen scammers impersonate banking websites and point to the padlock icon to convenience the victim that their website is legitimate. I think it’s for this reason, banks and cybersecurity experts should be a bit more careful when explaining how the padlock works to the general public. Regardless, I can’t deny that the current explanation is concise and gets the general point across.
In summary, we use HTTPS hundreds, if not thousands, of times per day. To be clear, this is a massive oversimplification. I didn’t even get into more complicated concepts like certificates or TLS. Part of the beauty of HTTPS is that despite all of the complicated processes that occur behind the scenes, you, the user, don’t have to do anything differently. HTTP addresses typically automatically redirect users to the HTTPS site. Even with all of the additional security measures added, web page loads are just as snappy as their HTTP counterparts. All of this to say, there are a lot of smart people working behind the scenes to ensure that your experience on the internet is as simple and secure as possible.
Citations and Notes
¹ Of course, in this universe, no one would open an envelope that wasn’t addressed to them. To keep this example simple, let’s ignore keys and bad actors for now.
² Butler, E. (2010, October 24). Firesheep. codebutler. https://codebutler.com/2010/10/24/firesheep/
³ Twitter. (2011, March 15). Making Twitter more secure: HTTPS. Twitter Blog. https://blog.twitter.com/official/en_us/a/2011/making-twitter-more-secure-https.html
⁴ Thank you Let’s Encrypt!
⁵ Schechter, E. (2016, September 8). Moving towards a more secure web. Google Online Security Blog. Retrieved May 31, 2022, from https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
⁶ The following site was very helpful for me in finding sources and pinning down exact dates, and it covers interesting points that I have not covered in this post, so I highly recommend checking it out.
Kaufman, J. (2018, March 8). History of HTTPS usage. Jeff Kaufman. https://www.jefftk.com/p/history-of-https-usage
One reply on “In Padlock We Trust – A Short Essay on HTTPS”
You’re the best!