HTTP vs. HTTPS: From the Outside, Looking In

Share on facebook
Share on twitter
Share on pinterest

This blog will cover the baseline for an understanding of HTTP and HTTPS. It will attempt to go as in-depth as possible, but I will most likely leave the more technical and complex things to our specialists as they will be able to explain in further detail.

What is HTTP?

HTTP (or Hyper Text Transfer Protocol) communicates between clients and servers using requests and responses. These requests are logged and accepted using the following steps:

  1. Your browser (the client) sends a request to a site.
  2. The request gets to the web server and is logged.
  3. An application is run but the web server to process your request.
  4. A response is sent via the sever to your browser.
  5. Your browser receives the response.

HTTPS is very similar. In fact, it deviates very little from the existing HTTP only it has much better security by adding a small number or simple extra steps.

Why is HTTPS Less Dangerous?

HTTPS is superior to HTTP as it has encryption. It uses an SSL certificate which applies a kind of authentication that the site is who it says it is, as well allowing for a trusted encrypted connection. This is very useful for websites where you provide sensitive data like passwords or bank details as it will stop hackers from being able to read it due to the encryption. Though this is the only significant difference between HTTP and HTTPS, it makes a huge difference to your online security.

If you are a website owner, for business or even personal use, Samurai feel there are no reasons why HTTPS should not be applied to your website due there being almost no drawbacks from using it over HTTP compared to the significant increase in security it can provide.

An Example of HTTP’s Security Risk

As for the story I was told, a small business-like establishment was opening near one of our specialists and he decided to investigate to see if it would be a place they would be interested in going (as it wasn’t far from where he lived). The business, as well as its website, would be potentially classed as sensitive in nature, so our specialist was perturbed to find the website used HTTP, especially in a context in which extremely sensitive data was collected (ID including photographs such as passports or drivers’ licenses as proof of age). Our specialist, wanting to assist the business and its patrons, got in contact with the spokesperson, informing them of the insecurity of HTTP and the security risks they were putting their patrons through. Unfortunately, the spokesperson didn’t take too kindly to the warning and sent back a rather rude reply (complete with expletives), saying ‘their family had been building websites for years’ and that ‘he didn’t know what he was talking about’. Naturally, our specialist tried to reach the spokesperson again, reassuring them that they were a fully trained professional with years working in the cybersecurity field and did not mean to offend anyone involved in making the website and truly just wished to offer some assistance and and raise their concerns. Then, the spokesperson changed their tune, claiming ‘nobody likes a smart alec’ and that because they were not a real business, the site would not require HTTPS.

While the site was not for an actual business, our specialist tried once again, to try & explain the issue to the spokesperson as politely as possible, as to not further any argument. However, they did not attempt to rectify their mistake. The spokesperson never did apply HTTPS and our specialist never visited the establishment even though he feels he would have liked to. The issues of the site in question were as follows:

  • Sensitive websites in question could be deemed inappropriate and while the URL would be made visible to a network admin if https was applied, they would not be able to view the content contained in the site to know what the was specifically looking at.
  • When the site asked for ID upload, this would upload the data in clear text. An attack on the same network could easily sniff out and gain this data stealing the victims ID or other input data.
  • ISPs and VPN providers or any other step the HTTP traffics would be passed through could have injected data into the page such as ads, tracking or worse (malware or exploitative code).

This story may be amusing to recount but it’s important to see the security risks that come with using regular, old HTTP, especially when dealing with web application traffic, and especially if transmitting very sensitive data that could have serious repercussions on a persons’ career, relations or family life.

A more in-depth and technical blog will be produced to explain the ins and outs of HTTP and HTTPS from a penetration tester’s point of view.

The latest cyber security news

Enter your email below to be notified when a new article is released.

Share this post with your colleagues

Share on linkedin
Share on facebook
Share on twitter