HTTPS stands for Hypertext Transfer Protocol Secure.
SSL stands for Secure Sockets Layer.
TLS stands for Transport Layer Security.
They’re all different things, but they’re all also very similar, and all of them achieve the exact same thing: secure communication over an insecure communication channel – like the internet – by encrypting the messages being sent so that only the legitimate sender and receiver can decrypt and read their messages to each other.
TLS and SSL are just methods of establishing that encrypted communication. TLS is just the newer, upgraded version of SSL.
HTTPS is just TLS or SSL being applied to the Hyptertext Transfer Protocol (regular HTTP), which is the communication protocol that most people use most of the time on the internet.
HTTPS is most known for the green padlock icon in your web browser’s address bar.
With HTTPS, you can be sure that the site you’re connecting to is really the website that’s shown in the URL, and that all your communications are encrypted so that only you and the website can read each other’s messages.
So let’s say I go to https://gmail.com and I see the green padlock icon. I can be sure that I’m connected to the real Gmail, and not some fake.
If, let’s say, a hacker tries to mislead me by connecting me to some website that’s not what’s shown in the address bar, my web browser would know and give me a huge warning like the one below:
That’s my web browser warning me that: “Hey, HTTPS isn’t working right, so I’m not sure this is the real website in the address bar.” But when I’m connected to the real website, I’ll see the green padlock icon.
These two properties:
- Allowing me to be sure that I’m connected to the real website, and
- Only me and the real website being able to read each other’s messages
Make HTTPS a great solution against Man-in-the-middle Attacks and DNS Hijacking. This is why making sure you type in the correct address in the URL and seeing the green padlock icon is so important.
HTTPS provides these guarantees by using asymmetric cryptography and the internet’s certificate authorities (CA’s). Every major web browser, from Google Chrome to Microsoft Edge to Mozilla Firefox and others, stores copies of all the public keys of all the CA’s. So when I connect to the real gmail.com via HTTPS, Gmail sends me a copy of its digital certificate that was issued by one of the CA’s. The digital certificate has a copy of Gmail’s own public key that I can use to securely start a conversation with Gmail.
The thing is, the digital certificate is encrypted. All digital certificates are encrypted with the issuing CA’s private key, and only the issuing CA’s public key can decrypt it.
Well, my web browser already has a copy of every CA’s public key. So my web browser tries to decrypt Gmail’s digital certificate and get Gmail’s public key. If my browser successfully manages to decrypt it, it proves that the digital certificate was issued by a real CA. The digital certificate also shows the name of the website that it’s for, which in this case is gmail.com. So I can trust the attached public key that is supposed to belong to Gmail and use that to establish a secure connection with Gmail.
ʕ·ᴥ·ʔ: That’s cool! But, uh, why doesn’t the browser just keep a copy of Gmail’s public key directly? Why do we have to go through a CA?
Oh, that’s easy. There are only a few hundred CA’s, so every web browser has to store only a few hundred public keys. If we instead directly stored every website’s public key, we’d be storing a few hundred million public keys, and have to constantly update that long list of public keys whenever a website goes up, down, or changes its public key. It’s much easier to have a few hundred companies do that for their customer-websites, and we just keep track of all those companies.