Blog post

Serve websites over HTTPS (always)

Created:  06 Jun 2018
Updated:  06 Jun 2018
Author:  Jamie H
https locks

Securing websites, so they keep user data private, is an essential element of the modern web. There are many aspects to this, but a couple of the most important are: ensuring that users see the site they are expecting, and that their data is protected when they send it to the site. Fortunately, both of these are easily achieved using HTTPS.

HTTPS (which uses encryption provided by TLS, the Transport Layer Security protocol) is a security technology used to protect website content while it's being delivered to the user. It both encrypts the content to ensure privacy and authenticates it, so that it can't be modified in transit.

As we state in our HTTPS guidance, all websites should use HTTPS, even if they don't include private content, sign-in pages, or credit card details. And this approach is starting to be enforced by modern browsers - in July this year, Google Chrome will start to mark websites not using HTTPS as insecure.

We anticipate other browser vendors adopting a similar stance to Chrome's on sites not using HTTPS exclusively. There are signs that this is coming, Mozilla Firefox and Apple Safari already have similar features for sites which do not serve sign-in pages over HTTPS, and Firefox will also be restricting its new features to sites which are using HTTPS.

If you are responsible for a website, and you want to test whether it's being served over HTTPS, all you need to do is visit the site. If you see the padlock icon in the status bar with no errors, everything is as it should be. Ideally you should test this on all the browsers that visit your site. If you're having problems, the NCSC has some useful reading on the use of TLS.

If you're in the UK public sector you can sign up to NCSC's Web Check service, which will now alert you if any of your sites are not using HTTPS. It will even tell you if your site looks misconfigured. You can then set about remedying the problem.

Jamie H
Senior Security Researcher


Dave Aitken - 11 Jun 2018
Some of the advice is out-of-date:
"If you are responsible for a website, and you want to test whether it's being served over HTTPS, all you need to do is visit the site. If you see the padlock icon in the status bar with no errors, everything is as it should be. Ideally you should test this on all the browsers that visit your site."
At least one browser has or soon will discontinue presenting a padlock symbol, on the basis that it will present a (strident?) 'Not Secure!!' alarm to the user visiting non-HTTPS
Jamie H - 12 Jun 2018

Thanks for your comment.

The removal of the padlock icon and replacement with negative indicators like "NOT SECURE" will have a positive impact on the web. The "NOT SECURE" text is a good example of the sort of error we suggest people look for when checking their site, as we mentioned in the blog.
SN Prasadd Dodla - 11 Jun 2018
Best informatie
Fabio - 24 Jun 2018
Hi I think the recommendation should be to encrypt the APIs as well.
Jamie Scaife - 25 Jul 2018
Also mobiles apps and embedded/IOT devices.
Si Smith - 26 Jun 2018
I thought your advice was to stay with TLS1.2 (as per Dr Levy’s recent blog on this, and the Gov minimum cyber standard), and avoid TLS1.3. This is advice I have received from my IA advisor. Please could you clarify?
Jamie H - 12 Jul 2018
We have not said anywhere to avoid TLS v1.3; it’s a great security improvement over TLS v1.2. In fact, Ian’s blog does say "TLS 1.3 undoubtedly provides better protection for individuals".
The challenge is that an interception technique currently used by many enterprises (either through choice or by regulation) becomes either impossible or unacceptably intrusive under TLS v1.3. Where this is not necessary, we would encourage the adoption of TLS v1.3 once it becomes standardised (in addition to well-configured TLS v1.2). Enterprises choosing or required to perform interception of particular content may need to block TLS v1.3 until a work-around has been devised.
tls_worrier - 05 Jul 2018
The HMG Minimum Cyber Standard says ONLY use TLS1.2 and not v1.3; Ian Levy's blog says TLS1.3 is bad for security - shouldn't this blog advising staying away from it?
Jamie H - 12 Jul 2018
The Minimum Cyber Security Standard requires the support of TLS v1.2, it doesn’t say "only" TLS v1.2. Ian Levy’s blog says that TLS v1.3 prevents some interception techniques currently used for content inspection, but not that it’s bad for security. In fact he states that "TLS 1.3 undoubtedly provides better protection for individuals".
We would strongly encourage the adoption of TLS v1.3 once it’s standardised (in addition to well-configured TLS v1.2).
Ian Macdonald - 12 Jul 2018
On a purely informational site with no logins, what on earth is the point of encrypting publicly available data which a hacker can download for himself anyway? Makes about as much sense as putting padlocks on free newspapers!

Furthermore, it is doubtful if HTTPS actually does protect against MITM attacks on passwords etc entered in pages with third party content - which make up the vast majority of websites. This is because the third parties such as advertisers are able to bypass the encryption. If it does not provide any proper or reliable level of protection on the majority of sites, then what is the real motive behind the enforced rollout, I ask?

The issue is not with HTTPS itself, which works when used as intended on one-to-one transactions, for example with a bank. It is with both forcing its use in situations where it cannot provide proper protection, and with claiming that it does provide such protection.

An analysis:
Jamie H - 13 Jul 2018
I don’t claim that HTTPS prevents all attacks, but not protecting your content is unacceptable.

Even when all of the content is public, you still want to make sure it can’t be modified without your knowledge. As I say in the blog, HTTPS "both encrypts the content to ensure privacy and authenticates it, so that it can't be modified in transit". You wouldn’t want someone to inject ads or malware into your page would you?

Troy Hunt blogged this morning about exactly this matter and agrees that you should always use HTTPS. (You can read it here:
Ian Macdonald - 14 Jul 2018
It doesn't provide any significant protection, because:

1: The majority of website hackings happen on the Web or SQL server.
2: Advertisers are immune to HTTPS security, and can modify or steal page content.
3: Google, the promoter of this initiative, is the major injector of ads into webpages.

Think about it, we've been using the Web since 1993 and malicious actors at data carriers have never been a serious issue. So, why suddenly now? OK I'm sure someone will pipe-up with a single odd case of such, but that is beside the point. It is a very low order of risk.

The people who are going to be hit hard by this are the small site operators, which include many charities and nonprofits. The use of free webspace will more or less be disbarred since such space typically doesn't support HTTPS.

Let's Encrypt is a Mickey Mouse workaround. It times out repeatedly and its reliability is poor. Been there, seen it, done that.

Besides, if a hacker can now use LE to set up spoof sites with perfectly genuine-looking HTTPS, and without going anywhere near a certificate issuer, then is that not a BAD situation? I'd say Yes, and in spades. By playing into the hands of counterfeiters, it destroys confidence in HTTPS where correctly and properly used, eg for banking.

Perhaps worst of all though, is the outright lie that the 'padlock' information tells to the user, in saying or implying that all data comes from the ONE certificated site. When, it does not.

If Google wanted to do something to actually improve Web security, they would post warnings on all sites using a (non-transactional) SQL database. Code injection being the No1 hacking risk, and the usual reason for a site carrying malware. (Transactional SQL is not much better since it still allows the coder to fall back into bad habits, and therefore guarantees nothing.)
Jamie H - 20 Jul 2018
I’m still not claiming that HTTPS fixes all security problems, but it does solve several. There are many organisations that provide free certificates, so HTTPS shouldn’t bring a noticeable financial cost.
Browsers are making gradual changes to make HTTPS the default of the web until HTTP pages will show "Not Secure" and HTTPS pages will no longer have any special indicators. In particular, a page will no longer be shown to be "Secure" simply because it does HTTPS, but will rightfully be called out as insecure when it doesn’t do HTTPS.
Ian Macdonald - 20 Jul 2018
Jamie, it's maybe not worth saying too much more in this since you seem to have some very inflexible views on the matter. However:

The issue is not whether it fixes all security problems, but whether it fixes the ones it is claimed to. Fit for described purpose, as the advertising regulators would say.

HTTPS is claimed to positively identify the source of data on the page, and to prevent MITM attacks.

On sites with third party content, 99.9% of the data could be from third parties, yet no mention of these third parties will appear in the certificate info. Any of these third parties could be running a keylogger or doing bitcoin mining in your browser. Or, whatever other nasty stuff that a MITM might do. Ergo, you are NOT protected.

It does bring financial cost, because the free options like LE don't work reliably or well.
Brendan Berney - 24 Jul 2018
This is a largely unnecessary proposal as well as being environmentally damaging. If a site does not require login credientials and does not store any user information then there is no point in adding TLS. All it does is add considerable processing overheads to both server and browser, which also adds to energy consumption for both ends of the transaction. With impending global energy shortages we should be pushing efficiency as well as security. I would add in terms of security we should probably be auditing the huge and out-of-control JavaScript stack instead.
Jamie H - 31 Jul 2018
Thanks for your comment. As I say in the blog, protecting your content from modification is always important, even when the content is static.
While cryptography used to be quite computationally expensive, this is no longer the case. CloudFlare has published a comprehensive analysis on the cost of web cryptography (, where they show that it’s roughly 1% of the CPU time of a typical web server. More complex web services will drive that portion down further, as the cost of other work increases.
Ultimately, securing your (and your users’) content remains really important, while the environmental impact is already small and will decrease over time.
Ian Macdonald - 31 Jul 2018
A related concern is that planned obsolescence may start to rear its ugly head, in the form of changes to encryption which are specifically designed to render all but the latest computers unable to access HTTPS sites. At the moment Windows XP computers can still run a HTTPS-compatible browser, but how long will that continue to be the case? Next for the chop, Windows 7?

There is enough 'waste making' already in the IT industry, without providing the vendors with another way to leverage planned obsolescence.

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No