HTTP vs HTTPS

Surfing the web safely and securely requires a basic understanding of the application protocols that websites use in order to communicate information. If you're wondering what HTTP and HTTPS are, your first and major experience is most likely the beginning of the domain that you're visiting. A website that is using HTTP will be prepended by http:// while a website that is using HTTPS will be prepended by https://. Most modern browsers make this distinction even clearer for the user by indicating a lock or an exclamation/warning marker in the left-hand pane of the URL bar. The lock indicates a secure connection over HTTPS and the other indicates an insecure connection over HTTP. Can you make a guess as to which we should be using? In this article we will dive deeper into the differences between each of these protocols as well as security best practices from the perspective of a basic user to a security professional.

Until 1995, the internet relied on the use of Hypertext Transfer Protocol (HTTP) to communicate data from websites to web browsers. That represented the typical communication that took place when a user interacted with websites using their browser. This was completely acceptable (for the most part) until the need for online financing, purchasing, and transferring of confidential data began to develop more heavily. In its infantile years, the internet ignored the necessity for many of today's modern security practices. HTTP communicated data in a cleartext format that was visible to individuals who were interested in digging into its content. You might say, why does this matter? Who cares about that data? Well, you should, because your information is collected and distributed by nearly every application that you use. That is a rant for an entirely different article but the takeaway is that you should be doing everything in your power to protect your information.

Can you think of the different instances where you have provided your information on a website that might have been something you didn't want anyone else to see? Perhaps your login credentials, bank account information, social security number, physical address, phone number, family members, security details, work schedule, medical information etc.  This is by no means an exhaustive list but each and every one of these details could be used to impersonate, blackmail, spam, extort, or phish someone for nefarious purposes. HTTP was especially helpful in this quest for sensitive information. Because of its cleartext communication, anyone who was technically savvy enough to sniff the traffic or who was willing to break privacy regulations, could use HTTP in a malicious manner. You never know who is listening/watching your conversation when you are communicating with a website. That is where HTTPS comes into play. You may not be able to stop someone from listening in but you can ensure that whatever information they do manage to get ahold of is complete gibberish.  

With the introduction of Hypertext Transfer Protocol Secure (HTTPS) in 1995, the security of internet browsing took a revolutionary turn. You may also see HTTPS referred to as Hyptertext Transfer Protocol  over SSL. As a disclaimer, HTTPS is the same protocol as HTTP but it uses SSL/TLS encryption to mathematically alter the data to a form that is only readable if the proper key is used to decrypt it. Before we begin talking about encryption/decryption, the simplest example that many of you have at least heard of is the Caesar cipher, otherwise known as ROT13. Can you guess why it's called ROT13? The concept of the encryption sequence is to shift or ROTate the characters forward by 13 places. Here is an example of this in the form of sensitive data that we are trying to pass to someone else who is on the other end of the communication:

This is my username
This is my password

After applying ROT13 encryption, the data would look like:

Guvf vf zl hfreanzr
Guvf vf zl cnffjbeq

Totally readable, right? We are really only interested in the username and password. If we look at these, we can see that the username=hfreanzr and the password=cnffjbeq. The only way that we would be able to recreate this information in a readable format would be if we knew that the encryption algorithm was shifting the characters forward by 13 places. To anyone who might have caught this transmission before it reached its destination or who might have somehow masqueraded as the recipient, this looks like a bunch of nonsense. This is an EXTREMELY simplified version of modern cryptography.

Using HTTPS, a webserver (website) obtains a SSL/TLS certificate from a certificate authority. When a user visits the website, the certificate is provided to the user via their web browser. What follows is the SSL/TLS handshake (covered in another article). This certificate serves multiple purposes. It proves that the website is who it says it is because it has been vetted by the certificate authority. The certificate also provides the user with a public key. This public key is one part of a two part system. The website maintains the private key (2nd part) while the user has access to the public key. These two keys allow the connection between the website and client to create a symmetric key (secret key). Yes, we've now mentioned 3 keys. Don't worry, asymmetric encryption uses 2 keys (public and private) while symmetric encryption uses 1 key (secret key). Each of these encryption algorithms has its positives and negatives.

Asymmetric encryption tends to be a more secure algorithm because it's more computationally intensive as well as requiring the use of two separate keys, one of which is NEVER released outside of the originating entity. Symmetric encryption is still a secure algorithm but is not as complex and only requires a single key in order to both encrypt and decrypt data. We can start to see the downsides to each of these in relation to their simplicity. Because asymmetric encryption is more complex, it uses more resources and takes longer to complete than its counterpart. Symmetric encryption can be completed more quickly but its failure lies in the transmission of the secret key. In the modern world where we are communicating over the web rather than yelling to the neighbor across the street, how could we get this secret key to its recipient in order to begin an encrypted communication? Asymmetric encryption, although computationally intense, allows for the transference of the symmetric encryption key in an encrypted format. That means that after that initial key exchange using asymmetric encryption, we can now rely on the speed of symmetric encryption to do the remainder of our communication. Wow we said encryption so many times. Encryption encryption encryption. Ok now that we got that out of our system, lets recap why we care about all of this.

Understanding how quickly technology advances and knowing the introduction of HTTPS in 1995, it should become glaringly obvious that HTTP is progressively becoming a deprecated protocol. That is not to say that it doesn't have its place. If you truly need to utilize speed, resources, and aren't concerned with the confidentiality of your data, by all means, use HTTP. Unfortunately, without HTTPS, you will be pretty much out of luck for obtaining a certificate to prove the legitimacy of your website. That leads us into what you should be looking for when you visit any website. It's honestly the first thing I look at and its that http:// in front of the domain name. For the most part, I would avoid these websites because: 1 - there's almost no legitimate reason not to be using HTTPS in this day and age, and 2 - you can't guarantee that this is truly the website you think it is because there is no certificate to prove its authenticity. If you find yourself on a website and aren't necessarily sure which protocol is being used, as we mentioned in the beginning, look up to the left hand side of the URL and you will often see some type of indicator as to whether it is secure or not.

To round this discussion out and forge forward with creating a more active security mindset, when's the last time you logged into your home network's router? Try it. Did you notice anything? Maybe that the connection is not secure!!! Oh no, that's not good. Well it is and it isn't, depending on how your network is configured. I would hope that everyone that has access to your home network is a trusted entity. If they're not, well you may want to think twice about entering your admin credentials to log into the router. But wait, why wouldn't my router's web interface be secure? Think back to the certificates and the authorities that provide them. They sign the certificate in order to verify the authenticity of the website. Your router is, most likely, using a self-signed certificate. That is not necessarily a problem but your browser really doesn't like it. Stay tuned for another article where we'll cover rectifying this issue.