ISPA Winner 2018 17 years of Krystal

Why HTTPS does not a secure website make

Steve Sant

By: Steve Sant in Security

Posted on: May 21st 2015 at 13:29pm

Forgive the Yoda style heading, but if ever there was some sage advice that webmasters should heed, it is this:

Applying HTTPS should be furthest from your mind when securing a website.

We couldn’t show Yoda, but hopefully this gives the jist…

Before you shout Outrageous!, Irresponsible! or other more colourful expletives let me put my inflammatory statement into context.

First and foremost, when I say “securing a website” I mean helping to harden a website internally so that it is less likely to leak sensitive information to unauthorised parties.

That’s not to say you shouldn’t protect the connection between the web browser and the web server, but it should certainly be regarded as just a very, very small part of your security strategy. There are plenty of other vulnerabilities to consider.

HTTPS has been dumbed down in the media to such a degree that it has become an up-seller’s fear-driven panacea for making a few extra bucks. Ask most people in the street (and in the boardroom) what the little padlock icon means, and they will often reply (with glowing authority) that it means a website is secure.

The awful truth about HTTPS

How SSL vendors like you to think about HTTPS

Anyone who knows that I am talking about will smile. Being accused of running insecure hosting by customers who believe their SSL certificate  secured websites to be akin to Fort Knox is one of the inescapable ironies of the industry.

Sadly, OpenSSL, the software commonly used to support encrypted application protocols like HTTPS, has been exploited again (heartbleed) and again (poodle), leaving hosting companies playing catch up to mitigate threats that could otherwise result in the disclosure of sensitive data.

HTTPS is only about protecting the connection between the client and server. Lets take a moment to review what this means, as it seems to be unclear in the minds of many. HTTPS serves two primary functions.

Secures the connection between a web browser and your website

This is a good thing – after all, anyone who has the right tools installed (which are freely available) might be able to break into your wifi connection. Or, if you use a wifi hotspot in your local pub/cafe, how do you know it’s safe? While these types of snooping go on, they are pretty rare – and SSL is intended to protect you against this kind of eavesdropping.

This protection isn’t without its pitfalls though – the aforementioned heartbleed and poodle issues are just two of a whole bunch of problems openssl has suffered recently. There’s also the matter of forward secrecy as not all web servers support this yet.

So, even though SSL is important, it must be done right otherwise you are just enjoying a false sense of security.

Authoritatively identifies your website

OK, so the other thing HTTPS does is confirm to your customer that they are really connecting to your website, and not some knock off copy. This is because SSL certificates have to be digitally signed by a trusted organisation, providing a chain of Trust.

Again, this system is not infallible. In practice, there are a number of ways someone could illicitly obtain a certificate for yourcompany.com – Firstly, if I was corrupt, I could just sell your existing certificate and private key files to someone (I don’t do this, by the way). Or, if a hacker had managed to gain access to your hosting account or one of your PCs, they could easily order a domain validated SSL certificate (the most common kind) and access the validation email that the SSL vendor sends out to your mailbox. Or, like the Iranians, you could just fool the certificate authority directly.

But again, this is all hard work – and very rare. Attacks involving illicit SSL certificates are only going to work if attackers can also dupe customers and possibly website owners into connecting to a bogus server (so they can extract data from them). This means the attackers usually also have to successfully execute some form of DNS spoofing/poisoning  on the DNS servers used by the victims in order to redirect them.

HTTPS does nothing to protect your website from attack.

How secure is your backdoor?

The point I’m making here is that both aspects of HTTPS (Security and Identification) are not perfect, and the technology is subject to an “open season” by hackers 24/7.

Lets suppose HTTPS was perfect – all that means is that the connection between the web browser and your website is private and secret. It doesn’t restrict who can visit your website – that is generally done by your website itself, through its own internal security model and permissions system. This is where the real danger lies.

There are, quite simply thousands of known (and unpublished) backdoor vulnerabilities in website software, and the most common types are:

  • SQL Injection – poor programming technique mean that it becomes possible to enter SQL commands into forms, search boxes, or directly into request URLs in such a way that it tricks the website into executing the SQL.
  • XSS Cross Site Scripting – One of the harder to understand concepts, but essentially this is about tricking a user who is logged into website A, into visiting website B, where a carefully crafted malicious link will trick the user’s browser to carry out actions on website A.
  • LFI and RFI – Local and remote file inclusion attacks allow attackers to upload files to websites either from local or remote sources. The WordPress attack that was discussed last week was just such an example of an LFI.

It is easy to leave a computer trawling websites looking for tell tale signs that one of them might be vulnerable to these types of attack. And when a vulnerable website is found, then it is almost always as easy to execute an attack using HTTPS as it is using HTTP.

Ironically, attacks that are mounted using HTTPS connection can actually present a greater risk to your website, than those that take place over plain HTTP.

The reason for this is that the attack can only be filtered and recognised when the data is decrypted, and the only place the data is decrypted is on the web server itself. Web Application Firewalls (WAFs) that are network based, are generally unable to filter the encrypted data stream because they don’t have access to the private key of your SSL certificate. Incidentally, Krystal filter both HTTP and HTTPS traffic.

So, using last week’s example, if a site was using the Gravity Forms plugin along with an ecommerce solution, then regardless of how fancy schmancy the SSL certificate might have been protecting it, it would have taken only moments to install malware that would have allowed an attacker to gain complete control, including downloading the entire website database.

This is why you should pay FAR MORE attention to upgrading and updating your WordPress, Joomla, Magento, Drupal core files, plugins, themes, extensions etc., than worrying whether or not to enable HTTPS and start handling sensitive customer data.

In fact, unless you are actively updating your site on a daily, or at least weekly basis, and have someone on hand who is keeping an eye on the security blogs, then for heaven’s sake – don’t even consider handling customer’s sensitive details or installing HTTPS.