What is HTTPS and why does it matter?

• April 2, 2014
• General

• Comment
• Facebook
• Google+
• Twitter
• Reddit
• LinkedIn

You might have seen some of our recommendations about the need to connect to websites via HTTPS whenever possible. Maybe you saw that instead of “http://facebook.com,” your browser said you were on “https://facebook.com.” Why would I be insisting that you type in that extra letter? Why would Facebook put that extra letter there without you even knowing?

Before HTTPS, you need to understand HTTP

When looking at a web URL, you are probably used to seeing “http://” before the rest. HTTP stands for “Hypertext Transfer Protocol” and has been the backbone for the creation and adoption of the World Wide Web. It refers to the specific way that you and the website you are visiting are communicating with each other and the servers that connect you. When you type in “http://en.wikipedia.org” in your web browser, what you’re really doing is sending an HTTP request to a server, who will recognize that URL and start the process that sends you the information that puts Wikipedia on your screen.

Once you have connected to the website, you will start an HTTP session. Basically, this means that the server putting you and Wikipedia in touch will be “listening” for more interactions between you two. This makes your future interactions, like entering a search query or clicking a link, quicker. While not technically necessary, many websites further speed up this process by storing all the data about your current browsing session on their webpages.

They can do this by either storing this information on their server until you log out (or, just keep it forever, but this is storage intensive) or by creating a “cookie,” which is basically the same concept but with the information stored on your browser. When you re-engage that website by clicking a link or entering another URL, you also send the cookie to remind the website what else you’ve been doing. This is the technology that keeps you from having to sign in over and over again. There are a few other ways of achieving this, but it is still the most common way of reminding the websites you access who you are.

Glaring security flaws exist with HTTP

Okay, I know you’re thinking that this HTTP stuff sounds just fine. There must be a catch, right? Indeed there is. Imagine mailing a note to a friend a few towns away. You don’t have any envelopes on hand, so you just fold it up and send it onward. You, as well as your friend, will have no idea who looked at your note while it was in transit. Likewise, your friend will not know if somebody altered the note, perhaps by adding to it. Of course, the theoretical postal service could just print out a new note that says whatever it is they wish it to say and deliver that instead. The same process could go on when your friend replies.

Now, as you might imagine, impersonation is fairly difficult even in this obviously insecure scenario. What isn’t difficult, though, is for the “man in the middle” to copy down everything you and your friend write to each other. So long as this doesn’t delay the delivery of your notes back and forth to a noticeable extent, nothing about this process will alert you to the spying that is happening in the middle. If you happened to write down your credit card number, you might notice some unexplained charges, though!

This is what it is like to connect to websites via HTTP. If anyone can jump in the middle, which can be more or less possible depending on the security of your network, the sophistication of the hacker, and the legal authority of the snooper, you won’t know that it happened and it will not be at all difficult for the man in the middle to see all of your data. What we have learned, the hard way, is that hackers are getting better and better at jumping in the middle. When you send that cookie or log in via an HTTP connection, that spy will be tickled to see your personal information, right there in plain text. Sending your cookie via HTTP ends up making available things like your login details, even when you aren’t in the process of logging in.

So how does HTTPS help?

If you’re wondering about the acronym, it is the same as HTTP, but with one apt addition: “security.” Going back to our mail analogy, HTTPS is a little more complicated. First of all, you have now put your letter in an envelope. One aspect of HTTPS is that you are much more likely to be able to find out whether your communications have been read. However, there is another security feature to consider: encryption. HTTPS connections are almost always encrypted by SSL/TLS, which is a protocol that is akin to your letter being written in code. Even if someone opens your letter, they shouldn’t be able to figure out what it says.

There’s a reason this doesn’t work perfectly, though. You have to, somehow, make your letter readable to its recipient. With HTTPS connections, your communications are automatically decrypted once they reach their recipient. This is reasonably secure, but you must have some certainty that you are communicating with who you think you are thinking with. For this reason, we have what are called “certificates.”

You might remember the very old school way of sealing an envelope, by using a personalized imprint on top of wax. So long as you were familiar with the sender’s seal, you had pretty good assurance that the letter you received was from who claimed to send it. This is exactly how certificates work. The SSL certificate is an official statement from the website you visit that says, basically, “yes, this is really me you are speaking to!” There are three types of certificates:

• Self-signed. These are not especially trustworthy. If you use Firefox, you’ll get a big scary warning every time you connect to a site via HTTPS that has a self-signed certificate. A self-signed certificate has nobody backing its claim to be who it says it is other than the sender. This is like your letter writer attaching a note next to the wax seal that says, “hey, this is really my seal.”
• Domain-validated. This is the most common and a generally trustworthy version. An outside entity, called a certificate authority, establishes that the owner of the domain you are visiting is also the person/group operating the website. You can be reasonably assured that you aren’t visiting a forgery, provided you typed in the domain correctly. The weakness of this protocol is, basically, that you must trust that https://espn.com is actually ESPN the company. Domain validation doesn’t seek to ensure that the owner of the domain is also the owner of the external entity that the website may claim to represent. Since websites like Getting Things Tech only exist as gettingthingstech.com, we never felt inclined to validate any further.
• Extended Validation. This has all the features of domain validation, but fixes up that last weakness I mentioned. When we check our GettingThingsTech.com email accounts, which are hosted on Microsoft Outlook (formerly Hotmail and Windows Live Mail), we see through Microsoft’s EV certificate that not only are we interacting with the owner of “bay182.mail.live.com,” but also the real-life Microsoft Corporation. Most modern browsers make this very clear by putting that name in green in the address bar like below:

The latter two, by using a certificate authority, offer you reasonable enough security for most situations. The extended validation is not as widely adopted as you might think; for instance, Chase Bank only uses domain validation certificates. Extended Validation is viewed by some as a money grab because they are extremely expensive to maintain (you don’t see that green bar when you visit Getting Things Tech!). For most purposes, having one or the other is just fine. If you’re ever suspicious of whether the website you’re visiting really represents the legal entity or company it claims to, then you should not divulge any sensitive information unless you see that green bar.

To go back to our analogy, these certificate authorities are like having a series of companies that keep track of everybody’s wax seal imprints. For domain validation, it is akin to me going to the hypothetical wax seal registry and making an imprint for them to show that it is mine. Extended Validation would be as if the wax seal registry required me to also supply a birth certificate, photo ID, and my last three tax returns to prove that “me” is really “Jacob.”

If you get a warning from your browser as you visit an HTTPS-connected website, take it seriously. There is some chance it is just a self-signed certificate, so read the message carefully to see if that is the problem. If you are just browsing that website, a self-signed certificate doesn’t necessarily have to scare you away; just don’t give them sensitive information over that connection. Sometimes, though, it signals that there is a “man in the middle” trying to deceive you by sending a fake certificate. In that case, don’t even navigate to the page.

What are the drawbacks?

Firstly, HTTPS is always better than HTTP. Even if there is some doubt about what’s going on, whether it’s you doubting the domain-validated certificate representing the site you think it is or wondering about a self-signed certificate, this connection is still encrypted. You will probably know if somebody is intercepting your web traffic. Even if you don’t, that traffic is encrypted. Hackers don’t even bother trying to crack this encrypted traffic; instead, they try to trick you into thinking they are a trustworthy entity.

The key here is to remember that there is no such thing as absolute security. You have to remain vigilant to things that don’t seem right and, more importantly, you never know what the intended recipient of your information will do with it! Google, when not selling your data for profit, is extremely secure. You will first want to realize that when you send your home address to Google, this is the sort of information that will be used for advertising. If you’re okay with that, you will probably be upset to learn that despite the fact their servers are guarded by real-life security guards and are located outside of the internet (so you can’t reach them by going to Google.com or “packet sniffing,” which is akin to eavesdropping on your home or ISP’s internet traffic), the NSA still was able to gather pretty much everything that Google knew about its users until recently.

It is important, then, to bear in mind that end-to-end encryption via HTTPS doesn’t protect you at…well..the end. There are a few ways that man in the middle attacks have occurred over HTTPS connections and might theoretically occur in the future, but measures taken in response to those lessons make things about as secure as you could hope for.

Check out our follow-up article on the subject of HTTPS connection vulnerabilities. Try to rest assured, though, that the vulnerabilities take a lot of expertise, probably a search warrant, and have to be targeted to particular people rather than dragnet data gathering that takes in large swaths of people at once.

Featured image by Chris Dlugosz (Flickr).

• browser
• internet
• privacy

COMMENTS