HTTPS is literally just HTTP, but shoved inside TLS, which is a generic encryption thing you can use on TCP* connections. It’s like shoving your message inside a magic envelope that can’t be broken into before you send it, the receiver can open the envelope though and read it. The stuff inside is still regular HTTP.

(*connections to a server that let you send/receive a stream of data, instead of just firing off packets and hoping they make it there like how UDP works.)

But as for HTTPS itself: First off there’s the encryption, which prevents anyone listening in from reading the stuff. But you also need to know that you’re talking to the right server, and some attacker isn’t just pretending to be the server you want and forwarding your messages to the real server, then relaying its answers back.

That’s where certificates come in. Those are, unfortunately, centralized at least as web browsers use them; there’s a Big List of allowed “certificate authorities” in each browser and/or OS, which are organizations you can get a certificate for your website from. Certificates are signed (more cryptography math magic) by the CA so that your browser can know the cert came from a known CA. If it doesn’t, it goes basically “huh? I don’t know who signed this! maybe an attacker did. I don’t trust it.”

There are other ways to handle that sort of trust. Mumble (a voice chat platform) also uses TLS certificates, but instead of just having a Big List, it just assumes that the first time you connect you’re not being actively attacked, and then if the certificate ever changes it can freak out and let you know. Much like SSH works (but SSH has its own completely different encryption scheme). Mumble also knows about the big list of CAs though and will accept ones signed by a known CA without questioning it.

– Frost