The web is moving to HTTPS, it has been for many years. We've seen an acceleration in the progress in recent months but we still have a long way to go on our journey of securing all traffic on the internet. Despite the great progress we're making, and all the valid reasons we should continue to do so, there are people that believe having a secure web is not the right thing to do.
The web is moving to HTTPS
I regularly scan the Alexa Top 1 Million, the 1 million largest sites on the web, and measure many different metrics about their security. One of the things I look at is whether the site redirects you to HTTPS if you connect to it using HTTP and that metric has seen some impressive growth over the years. You can see all of the reports I've published here and the most recent one from Feb 2018 here. The growth of HTTPS is not only being maintained but it's actually accelerating.
No matter which way you look at the data, and no matter which way you measure it, usage of HTTPS is going through a huge growth phase right now. In the 6 months up to that report we saw a 32% growth in the use of HTTPS in the top 1 million sites.
It's not just me making these claims either, you don't have to take my word for it. Mozilla tracks anonymous telemetry from Firefox browser and they have seen a staggering growth in the rate of pages being loaded over HTTPS.
The data shows that 75% of page loads in Firefox now take place using HTTPS instead of HTTP. That's a phenomenal number but we do still have another 25% to go!
Lastly, the biggest browser of them all also reports the exact same thing. Chrome telemetry puts the figures pretty much right on 75% too.
This trend has been showing for a long time. In fact, there isn't any data I can find that shows there was ever a decrease in the amount of HTTPS on the web. It has always been increasing since as far back as data goes so this is nothing new, we're just making much better progress in recent years.
Arguments against securing the web
Not everyone is happy with the web moving towards a secure future and there are various different arguments against it. I'm going to look at a few arguments from prominent people in the industry to those outside of our industry but with huge social reach. I often see a lot of anti-Google rhetoric on the web but never so much as when talking about HTTPS. It's time to dispel some myths and common arguments against having a secure web.
Dave Winer
Dave Winer is a fairly prominent person speaking out against the idea of securing the web. He has a pretty extensive Wikipedia page and of course his website is only available over HTTP. From reading many of Dave's posts his problem seems to be more about disliking Google than it is about disliking HTTPS. Google have been a huge player in driving the web to be secure but we have to remember this is an industry wide effort in which countless organisations around the world are participating. Still though, that doesn't stop Dave targeting all of his criticism at Google. Here's a selection of his recent articles:
Questioning Google's motives re the push to HTTPS
It's pretty easy to see that Dave's problem really is with Google here and I disagree with this on many fronts. First, it immediately discounts the tremendous work that thousands of other people at countless organisations are doing and second, the constant insinuation that Google has some evil, ulterior motive to making the web secure is never substantiated. In particular, in another article Google and HTTP, Dave continues to drive the assertion:
I've been writing about Google's efforts to deprecate HTTP, the protocol of the web.
Let's clarify right away that this is nonsense. Google has never said they're going to deprecate HTTP, the only things that have been said are around changing visual indicators for HTTP and HTTPS in the browser, HTTP will still work exactly as it did before. This is a common thing though where Dave takes something as simple as changing a visual indicator in the UI and then mispresents it as Google switching off HTTP for the web which just feels like a click-bait headline. There was one instance though of Dave pointing some focus towards Mozilla and their efforts to make the web secure for everyone when he spoke about a ticket on Bugzilla to "Switch generic icon to negative feedback for non-HTTPS sites", Mozilla also mentioned this in 2015. Dave's response on Mozilla's internal dialog on HTTPS is predictably provocative. First, this isn't "internal dialog", it's a public bug on Bugzilla, but isn't "internal dialog" a much juicier headline. Throughout the article there's a similar trend.
they decided to put a big red X through the icon for sites that are using HTTP, the standard protocol of the web, instead of their preferred HTTPS.
It's an argument against control because Mozilla is acting like a government. They have decided that if you want to continue to publish to users, you must comply with the new regulation established by Mozilla.
I wonder if they've even tried to quantify the outages they'll cause.
I suspect once they start putting red X's on sites that people care about, and their support people start handling calls saying the browser is broken, they might put this back on the list, as an urgent bug
This common theme again of breaking the web is a massive, and I suspect intentional, false claim. Nowhere in that ticket did Mozilla talk about stopping HTTP sites from working, in any way. It was simply progress in evolving the UI indicator to change it from one thing to another and Dave has blown it out of all proportion to suit his line of opposition. No one is going to stop HTTP from working as it does now, the user will just have accurate information about connection security in the UI. Thing is though, Dave likes to pull rank on you if you ask him about these things (even if you have a much stronger following than him).
You have no idea who I am, do you?
— scripting.com (@davewiner) February 22, 2018
Who are you?
— scripting.com (@davewiner) February 22, 2018
Maria Johnson
"Maria Johnsen is a hyperpolyglot entrepreneur, best selling author, film producer, influencer, speaker, programmer and multilingual digital marketing expert." You can find her on her site and on Twitter but I couldn't tell you much about what she's been up to recently.
With over 200,000 followers, and claiming to be a cyber security expert, Maria has quite the reach to influence people's views of HTTPS. That said, with claims about HTTPS being slow and expensive, and easily substituted by a good firewall instead, that reach isn't always being put to good use. HTTPS hasn't been slow for quite some time now, just check out istlsfastyet.com or httpvshttps.com and all of the benefits you can get from HTTP/2 which requires TLSv1.2 in my blog post HTTP/2 is here!. On the cost front we've had Let's Encrypt for over 2 years now and they dish out free certificates to anyone who wants one and CDN providers like Cloudflare also have free SSL offerings in the form of Universal SSL for all of their customers. On top of that sites like GitHub pages have had HTTPS support on their managed domains for 2 years and now even do it for free on custom domains, so do wordpress.com and Ghost. I think the point here is pretty clear and proof that HTTPS is not expensive and is available by the spade. If you want to encrypt your own site there has never been an easier, cheaper or better time to do it and there's a good chance your platform will already do it for you or soon will.
Oh, and no, a firewall is not a suitable replacement for HTTPS.
@hydrajump @Scott_Helme @troyhunt pic.twitter.com/Ls1x2GlPCe
— Paul Wilson (@pwgolfer) June 17, 2016
Neil Patel
As another SEO expert (there's a theme here...) Neil Patel has close to 300,000 followers on Twitter and almost 1,000,000 on Facebook! That's some pretty big reach so hopefully Neil is supportive of the HTTPS cause.
Well, maybe not! Troy already did a pretty good article on the whole Neil Patel story after he left some really constructive and helpful comments on a Facebook post of Neil's about HTTPS. The comments were deleted, along with those from many others about why we really do need HTTPS, and the whole incident wasn't really helpful to our cause of securing everyone on the web. It doesn't matter what a page contains these days, any insecure content is a great avenue for passive monitoring, active attacks like MiTM and MiTB and introduces a whole heap of other issues.
Bryan Lunduke
Bryan Lunduke of The Lunduke Show has a pretty substantial social following and has covered HTTPS in some of his shows which you can find here.
Now, the titles for both of those videos certainly caught my eye but specifically the 'HTTPS is dangerous' one. It also has a pretty interesting description.
In the video Bryan addresses what he sees as quite a few serious issues with HTTPS and I'd like to go through them all here and address why the assertions he's making aren't accurate.
Problem 1 - Certificates Expire
According to Bryan the fact that certificates expire is a built in problem with HTTPS, there is an inevitable point in the future at which the system will fail if you don't intervene and replace it. (the videos are linked to the right time, just hit play)
I've spoken before about certificate lifetimes right here on this very blog and why, as an ecosystem, we need to do better in this regard. But doing better isn't making certificates valid for longer periods, it's making certificates valid for shorter periods. To increase security on the web we need certificates valid for less time. The CA/Browser Forum has been progressively reducing the maximum age for certificates from 10 years right down to 2 years where we currently are. My hope is that next year we could even see certificates capped at a 1 year maximum age.
Problem 2 - Fake Certificates
In the same video we hear about the 2nd problem which is that certificates can be faked very easily. Bryan goes so far as to say that this is 'trivial' to do.
Now, there are a couple of meanings I can think of for what Bryan means by a 'fake' certificate so I'm going to cover them both to make sure I've covered all of my bases. The first would be a mis-issued or rogue certificate which is when someone manages to obtain a certificate from a CA that they shouldn't have. Maybe they tricked the CA, bribed them or hacked them, but they get a certificate from a genuine CA that they weren't supposed to have. This can and does happen but we need to understand how crazily rare an event like this is because the CAs desperately don't want this to happen because it can result in them being shutdown.
The second would be where a valid signature was forged on a certificate to make it appear genuine when it wasn't and this is a much trickier proposition. At a minimum this requires someone to be able to generate a hash collision, specifically for SHA256, and that's no walk in the park. We've only seen an attack like this happen once before in history and it was done against MD5. We quickly migrated away from MD5 to SHA1 and we've since moved away from that to SHA256, all in an effort to make sure we're consistently using a strong hash function that's resistant to collisions. To say that this approach would be easy or trivial is also a little on the crazy side as it's just not going to happen. That said, even if it did, even if either of the two things I've just mentioned did happen, we now have a pretty reliable way of finding out about it too and that's Certificate Transparency.
I don't want to delve too deep into CT because you can read my blog about it, Certificate Transparency, an introduction, but essentially it makes it impossible for there to exist a valid certificate for your site without you being able to know about it. That means if someone did get a rogue cert or manage to forge their own, they'd have to log it into CT and you'd be able to see it, alerting us that such an event had taken place.
Problem 3 - SHA
The Secure Hashing Algorithm is exactly what it says, a hashing algorithm that's secure. Except it isn't, because it was made by the NSA and the NSA have a backdoor into SHA.
Now, I kind of touched on what most of the problem here is in my previous point and why this isn't really a problem. Let's play out the scenario and assume that the NSA actually do have some kind of back door into SHA. We don't care about reversing a hash (in the context of signatures) so I think the premise of them being able to 'un-hash' something isn't the concern, it instead would be that they could generate hash collisions. The whole point is that no two files have the same hash (a hash collision) and if you can make two that do have the same hash, we have an issue. With the ability to do this the NSA could forge signatures on certificates and issue themselves whatever they want whilst making them look like perfectly genuine certs. This means they could then impersonate websites and decrypt traffic to and from them between the browser. First of all, we've never seen any evidence that the NSA has a capability like this and it'd be pretty obvious in a given scenario if this was the way they got access to the data. Also, coupled with the CT point just above, this is becoming less and less possible with every day that goes by because if the NSA wanted the browser to accept their forged cert, they'd have to publish it publicly in the CT logs, and we haven't seen any of those yet either. Oh, and of course SHA-3 is broken too because NIST were taking advice from the NSA.
Problem 4 - Complexity
The 4th problem with HTTPS is that it adds more complexity to the system and as a result it adds more vulnerabilities within the system.
Before I address the kind of overall point here that more complexity equals more chances for things to go wrong, I just want to make sure we understand why this just absolutely doesn't apply. We take a HTTP website, we migrate it to HTTPS, something in the HTTPS is deployed/configured/used wrong and worst case scenario, the HTTPS gives us no protection at all, we're essentially using insecure comms. Broken HTTPS is just HTTP. It doesn't put us in any worse situation, it's just like it wasn't there to protect us. Now, for the 99.999999% of time that people deploy HTTPS and get it right, we get all of the awesome protection that HTTPS does offer.
I think there's enough in there to disprove all of the problems raised but there are also some other pretty concerning quotes in this first video:
It's not so important that the numbers be random
Any hacker who's read enough Reddit pages can break HTTPS
HTTPS is downright dangerous
Moving on to cover the second video quickly, 'Why I don't use HTTPS on my website', there are a couple of main reasons here too.
Reason 1 - Compatibility
Netscape Navigator 3.0 (released August 19, 1996) on Mac OS 8 (released July 26, 1997) doesn't work with modern version of HTTPS, so HTTPS is bad, mmmk?
Just to prove the point, here it is working on HTTP!
Now let's not mention the literally countless other things that wouldn't work on your website, without even thinking about HTTPS, but I still tried to find some stats on the usage of Netscape and I really struggled. Most stat counting websites don't even have an option for Netscape for me to select to actually see their market share and the total of the other browsers comes to 100% so I can only assume there really is none.
Reason 2 - DRM
I'm not quite sure how this one plays out in the world of HTTPS, but HTTPS is DRM!
Because HTTPS requires certificates, and certificates expire (see previous points), we have DRM on content. This just isn't how HTTPS certificates work and just because a certificate expires, it doesn't mean the content disappears or can no longer be downloaded and lost forever. That's just not what happens. To close off, there are a few more quotes in that video that give me cause for concern too.
If I were running The First National Bank of Lunduke HTTPS would have a real purpose
[HTTPS] is planned obsolescence
HTTPS is a mechanism for DRMing a website
Lots of bad information online
We are making really great progress on encrypting the web right now as all of the data out there, including my own, shows, but we need to be doing better. Information like the small sample I provided above is not helping that cause and as we've seen, trying to correct it isn't always easy or even successful. If you do see things like those I've shown above, and I'm sure there must be loads of them out there, maybe drop a friendly comment in the comment section and point them to some good resources on why HTTPS is great for everyone. We need more information out there educating people about the benefits of an encrypted web and less information slowing us down.
References
https://scotthelme.co.uk/https-deployment-tips/