Extra security sounds appealing — it's one of those things you'd rather have than not — but the term "HTTPS" often gets thrown around without a lot of explanation or context. As a former site administrator and someone who has given talks on HTTPS, I'll take a swing at explaining it in regular language below.
What HTTPS is and what it does
Normal HTTP traffic is unencrypted and travels over TCP port 80 (by convention). Because it is "sent in the clear," it is vulnerable to what are called "man in the middle" attacks. Using our favorite cryptographic personas (Alice, Bob and Chuck), we can see how that would work.
Alice is a user, and Bob runs a website. Chuck runs an Internet cafe. Alice goes to the cafe, and uses the free Wi-Fi Chuck provides. What Alice doesn't know is that Chuck is sniffing all the network traffic that goes through his Wi-Fi router. When Alice sends credit cards, usernames, passwords, and other sensitive information to Bob's site, Chuck sees them too, and he can use them for his own fiendish purposes. Or Chuck can even set up his router to send Alice to a fake site Chuck runs, that spoofs Bob's site.
Without HTTPS, Chuck (center) can potentially extract sensitive information.
HTTPS solves these problems by offering encryption to prevent sniffing and authentication to prevent spoofing. To understand how, you need to understand how public key encryption (PKE) works at a basic level.
In PKE, an entity (a company, individual, etc.) creates a public and a private key that are linked to each other. Using the public and private key, you can do a number of interesting things. Let's suppose that Bob has generated a public and private key, and given the public key to Alice.
- Alice can use the public key to encrypt a message, and only Bob can successfully decrypt it.
- Bob can take a message, "sign" it with his private key, and Alice can use the public key to ensure that it came from Bob, and the contents haven't been altered.
When Alice connects to Bob's site using an HTTPS connection (traditionally port 443), the first thing Bob's site does is to send down the public key for the site. In most cases, Bob got his key (wrapped in something called a certificate) from a vendor such as VeriSign or Thwate. These firms made sure Bob is who he said he is, and signed his public key with their private key.
When Bob's server sends his certificate to Alice's browser during the first stage on an HTTPS connection, Alice's browser does a few things:
- It makes sure that the certificate is for the site that Alice tried to connect to. If there's a mismatch, Alice will see one those error messages that warns a site isn't what the certificate says it is (more on certificates below).
- It makes sure that the certificate hasn't expired (most certificates are issued for a period of a year.)
- It makes sure that the certificate was signed by a "trusted" authority like VeriSign.
Browsers ship with a set of public keys for the major certificate authorities. If a certificate is received that wasn't signed by one of the big players (such as in so-called "self-signed" certificates), you'll get a different warning message from your browser.
Now that Alice's browser has Bob's certificate, which includes Bob's public key, it generates a unique cryptographic key (in encryption jargon, a one-time pad) and encrypts it with Bob's public key. The browser sends the encrypted key back to Bob's server, which uses Bob's private key to decrypt it. From then on, all the traffic back and forth is encrypted using this one-time key.
HTTPS keeps Alice's information secure.
This neatly solves all the problems that let Chuck make mischief. If Chuck intercepts the first return message from Bob's server, all he gets is Bob's HTTPS certificate, which he can get himself by making a connection. If Chuck intercepts Alice's response with the one-time key in it, he can't decrypt it because he doesn't have Bob's private key. All the traffic after that is encrypted with that one-time key, so Chuck can't read that either.
If Chuck tries to spoof Bob's server, he won't have a certificate signed by a trusted authority that matches the site's web address. If Chuck sends back a bogus certificate, it won't be signed correctly and the browser will put up a warning. Chuck can't use Bob's certificate, because he won't be able to decrypt the one-time key coming back to him.
By offering (or forcing) users to use HTTPS, sites like Twitter are making sure that the connections are safe from eavesdropping and the users can be assured they're actually talking to who they think they are. HTTPS has been a mainstay of financial websites for years, especially any site that takes credit cards. By adding it, Twitter is recognizing that a Twitter username and password, in the wrong hands, can be damaging (if only to someone's reputation, as opposed to their wallet.)
What you should do when you see a warning
When certificate warnings appear, you should look at them carefully (most people don't). If it's warning that a certificate has expired, that's probably okay for a small site, but worrisome for a big one. If the mismatch is something like www.bankofamerica.com vs somethingelse.bankofamerica.com, you're probably okay, because they still had to prove that they were Bank of America to get the certificate.
If it's a total mismatch, even something subtle like www.bankofamerica.com vs www.bankofamerica.co, be very careful. If you can, you should call or email the site managers to inform them of the issue and get clarification. Put another way: If Chuck managed to hijack Bob's DNS and all the traffic to Bob's site might be flowing to Chuck, that's something Bob probably wants to know about.
How much faith should you put in HTTPS?
For anyone but the NSA, HTTPS is pretty much a sure thing that no one can intercept the connection.
But before you get too comfortable, it's important to understand HTTPS is not an all-encompassing security measure. In the Twitter and Facebook examples, the HTTPS security only applies to the official web interfaces (i.e. Twitter.com and Facebook.com). If you're using a third-party client to update your Twitter or Facebook pages (such as an iPhone app), you won't be protected by HTTPS security unless the application has been configured by the developer to use HTTPS to talk to the service.
HTTPS doesn't protect you from bigger issues, either. You can still run into problems if a virus is keylogging your computer, or someone is breaking into the database at the website. Nor does HTTPS ensure that your data won't be compromised before or after it's transmitted over the web.
Finally, HTTPS won't do anything if you don't look for the warnings, or — and this might seem obvious but it's worth repeating — if you don't put it to use.
Illustrations by Robert Romano.
- HTTPS is more secure, so why isn't the Web using it?
- Web users ignoring security certificate warnings
- Cyber warfare: don't inflate it, don't underestimate it
- How to prepare for a cyber attack