This post was originally written for my Freshman Seminar ‘Big Brother is Watching: Internet Security and Privacy’ with Prof. Brian Kernighan. It’s written to be very accessible, but still caters to a somewhat technical audience. I recommend you check it out – you might just learn something!
This page that you are currently viewing was supplied to you by one of the most commonly used protocols on the Internet: HTTP. More specifically, HTTPS which is the real topic of this post, but more on this later. The HyperText Transfer Protocol is indeed rather amazing, facilitating nearly all information as viewed by visitors of my website and most other websites like it. However, HTTP is far from perfect and I will argue that it has become completely obsolete due to security risks. Anyone intercepting the information sent back and forth to my server hosted in Sweden can not only read it but also change it without the server nor the user knowing; let me explain.
HTTP was first developed at CERN in 1989 and since the standard has been altered and upgraded several times. The protocol is based on requests and responses between clients and servers; in this case that would be your browser and the software hosting my website on a computer somewhere in Sweden, respectively. The protocol facilitates the sending of a request by the browser asking for some information from the server. The server would then return a response consisting of general information and whatever was requested. Of course, all of this information is sent in clear text, meaning it is legible by any one of the possibly dozens of computers facilitating the transfer of the information between the server and the client. Furthermore, as these computers are relaying the information they can also alter it. This is generally referred to as a man-in-the-middle (MitM) attack.
Say for example that I wanted to start a fund-raising campaign by encouraging people to send Bitcoins to the Tor Project. Perhaps then I would post their Wallet Address on this website, to which you could then send your Bitcoin donations.
Until very recently, before I updated to HTTPS on this site, you should not have sent money to the address above, not because The Tor Project is not in need of support but because the wallet address above was supplied to you by way of HTTP – meaning it is subject to a MitM attack. If someone on your network decided they could make better use of your kind donation they could just intercept the page and replace the address with theirs, and you would have no way of knowing, nor would I.
This is where HTTPS (notice the S for Secure) comes in as an excellent solution. HTTPS uses either TLS or SSL for encrypting the data traveling between the server and the client – hindering any reading or altering of the information by any man, as it were, in the middle. The encryption works through the surprisingly straight-forward idea of a handshake. In turn, a handshake builds of the concept of asymmetrical cryptography. In its simplest form, it consists of a pair of keys, one private and one public. The public key belongs to the server and is shared with the client who uses it to encrypt data to be sent to the server. This data can then only be decrypted through the use of the private key in the safe hands of the server and the server only. After some technical negotiation between the server and the client, the latter sends a pre-cursor to a so called shared secret, encrypted with the server’s public key. The shared secret, in contrast to the private/public key pair can be used to both encrypt and decrypt information. As such a secure connection is established: the client generated the pre-cursor and sent it in encrypted form to the server, making them the only two entities who can calculate the shared secret. This key can now be used for however long they want to securely transmit information back and forth.
Of course, there is one last issue: how do you, the client, know that the public key that you received from the server was not compromised and replaced with someone else’s key? This would mean the secret you sent was received by someone else entirely, and that you were never communicating with the intended server at all. This is where certificates come into play. Instead of using any old public key, the server buys an authenticated certificate from a so-called Certificate Authority, clients can then consult the trusted authority on whether or not the server they are attempting to connect to are what they make themselves out to be.
Until recently, these certificates were rather costly as they were targeted toward large corporations. Furthermore, they required extensive legal work to supply authentication, again due to the fact that the services were targeted toward corporations with the required resources. Nowadays however, most anyone can find a cheap yet secure service, which in extension means there is no excuse for me, nor for anyone else, not to use HTTPS. Still I (until recently), and 38 of the top 100 websites on the Internet, do not use HTTPS – at least not correctly. Why is this?
Looks like it was worth it. (s: https://www.whynopadlock.com/)
I will not pretend to be able to answer this question conclusively but I believe it comes down to two issues: lack of education and good old laziness. Before taking a Freshman Seminar on the subject of Internet Security and Privacy I simply did not realize the risks of not using HTTPS. I thought that since I did not have any login service there was no reason for me to worry about secure communications. Of course, there is more to be protected than just login credentials. The Bitcoin wallet example above is certainly a scary one. Another thing worth mentioning is the fact that HTTPS limits meta-data as well. No one would be able to see exactly what post you are viewing right now, only that you are on my website, had I been using HTTPS. This is useful for big sites like Wikipedia, a tracked user could read most anything on there, and someone monitoring the connection would not know, because the only unencrypted information would be ‘https://www.wikipedia.org’.
I just got HTTPS up and running last week. It was ridiculously easy now that my host implemented a quick way to migrate. It was literally as simple as the click of a button.