Skip to content

Why HTTP is bad

We've become accustomed to seeing HTTPS on our websites, yet there are still some that simply refuse to use HTTPS. Our favourite Bureau of Meteorology is exactly one such case.

Who cares about encryption?

This is an argument I hear all too often.

"The data is not secret, there's nothing sensitive about it. I don't need HTTPS"

If you're the operator of our weather service, you may be partly right - there is a "publicness" to the data that likely does not warrant full encryption of the data. I'll give you that one on the confidentiality aspect of the CIA triad. But that's not the full story...

Who are you?

Is it that you're connecting to?

HTTPS has another hidden feature - confirming the authenticity of the parties. At the very least, a certificate is attached to the DNS entry it is connecting to. Even though BOM does not officially support HTTPS, the SSL test for their HTTPS endpoint does indicate that their site belongs to * This means it's a wildcard certificate, so there's one certificate issued for all sites that may sit beneath the domain. That's ok - companies do that from time to time to ease the burden of reissuing certificates. It does come at a cost though.

If your API or site is really important, like a banking portal, for example, I would argue that the portal itself is such an important asset, that it warrants its certificate. The only drawback with a wildcard certificate is that a test or dev site could be created within your organization and use the same certificate. So if allowing users to authenticate who and what they are connecting to is important to you, issue separate certificates.

From an availability perspective on the CIA triad, this is where HTTPS starts to show its colours.

Data integrity

HTTPS is not just about encryption and protection against confidentiality. Integrity in the CIA triad is quite important here.

Is the data I just downloaded the correct data, free of interference or tampering?

Without HTTPS, you cannot make that claim.

I was developing a personal website a few years ago. I was traveling overseas at the time, and I was working on the website from my hotel room. I ran into an issue...Every time I tried to access my site, some rogue code appeared. The site broke during my testing because of this rogue code. It turns out the hotel I was staying at was injecting their own JavaScript into all HTTP connections for tracking purposes. I picked up on this because I started noticing code appear in my feed that I did not write.

In this example, it was fairly benign, but it did highlight an important point. If there is no HTTPS in place, anyone can intercept the traffic and inject some rogue code in there. What if the code was bad? What if some bad actor injected some Crypto Mining code, or a screen scraper in the HTML? My site would be blamed for injecting the rogue code, even though I had nothing to do with it.

Renew those certificates

Too many times companies forget they have a certificate in place. Be sure to rotate them when needed. The last thing you want is for your customers to be warned that your site is not secure because of an expired certificate. My certificate for this site is hosted by AWS, and their certificate manager automatically rotates the certificate for me. If your hosting provider offers you that service, do sign up for it.

What's the BOM's excuse?

Who knows to be honest. Government agencies have their reasons. I had a look at BOM's website. sits behind the Akamai CDN service that offers all sorts of security solutions. It is a simple task to enable HTTPS on their site (HTTPS is already active, they just actively redirect you back to their HTTP site).

The only plausible "excuse" I can think of is that the BOM has plenty of public clients who may have technical difficulties in dealing with TLS/SSL traffic. Some lower-end devices like IoT devices may also be consuming this data, and the performance overhead on a smaller, low-powered CPU to perform complex encryption processes can be overwhelming. Being government, they are also very likely not to enlist a strict end-of-life policy on equipment, so there may still be plenty of older equipment floating around the country, hence they're locked in using a legacy piece of technology.

What can I do?

  • Test your site at SSLLabs to see where the gaps are.
  • Sign up for a free Let's Encrypt certificate, and apply it to your server.
  • If you're an AWS customer, you can also get free certificates through AWS Certificate Manager. (You may need to attach it to a CloudFront distribution as well - this part is not free).
  • Avoid wildcard certificates if you can, and issue a cert for every endpoint.