HTTPS, short for Hypertext Transfer Protocol Secure, is a digital communication protocol that defaults to port 443 and nowadays sets the bar for minimum acceptable data security on the Internet. The standard was originally also known as HTTP over SSL, which was a name that reflected the Secure Sockets Layer encryption that was in use. Following that logic, it’s technically correct to refer to its latest implementation as HTTP over Transport Layer Security (TLS) as that’s literally what it stands for. Not that anyone does, mind you.
Don’t let the fact that TLS often gets dropped from the actual name of the service fool you: HTTPS *is* TLS. It lives and dies by the security properties of the said cryptographic protocol. Without getting into too many technical details, TLS communications use semi-static public and private keys to generate session keys on a per-connection basis. A successful connection is always denoted with an “https://” designation inserted at the beginning of a given URL address.
Because public keys are in the mix, HTTPS wouldn’t be possible without third-party authorities verifying their authenticity. These keys do change over time, but TLS certificates usually last years, not to mention cost money, however nominal that amount might be.
Of course, replacing public domain certificates with some sort of private, dynamic keys would up the overall security of HTTPS. It would also skyrocket the costs of domain management without eliminating the need for third-party authenticators. On the contrary, that would simply mean sending even more business their way.
The primary HTTPS failsafe: forward secrecy
Note that certificates aren’t immune to getting compromised. The very inclusion of another, third party into the protocol makes it more susceptible to certain attacks. This isn’t a cybersecurity issue as much as it’s a systemic phenomenon – a more complex system with a greater number of moving parts has more potential failure points. In the case of HTTPS, the existence of certification authorities increases the threat posed by some type of man-in-the-middle attacks. Even though the protocol is meant to do the exact opposite, on the whole.
That’s why the so-called forward secrecy principle is important in modern-day HTTPS applications. In simplest terms, forward secrecy guarantees communications will stay private even after their conclusion. Meaning the only way HTTPS data packet exchange can be compromised is if an attacker reverse-engineers or otherwise discovers an applicable key while the session is still on, which is extremely unlikely to happen.
With that said, only 1% of all currently active web servers lack any kind of forward secrecy support, according to a Qualys survey from February 2021. The specification, on the whole, became the new norm by 2018. As that’s when Google Search started penalizing websites not secured with HTTPS. Save for the aforementioned certification fees and a few changes to applicable cookie settings, there’s not much more to compliance, from a technical perspective.
HTTPS vs VPN
For the average netizen, HTTPS is important because it’s often their first and always their last line of defense against packet injection attacks. The kind that threatens to sniff out personally identifiable information they share with specific websites or implements even more ads into whatever frontend happens to be in front of them, no pun intended.
In other words, accessing websites over a public Wi-Fi connection without HTTPS protection is a big no-no. Unless your setup allows for a different form of encryption, usually by the way of a virtual private network. VPNs are more comprehensive solutions than the HTTPS specification, which is by design. Because using a VPN means encrypting all of your outgoing Internet communications, usually at an OS level. Whereas HTTPS only works on the basis of individual browser instances and their specific connections to websites that support it.