Deprecating HTTP
Mozilla have recently announced that they are planning to deprecate insecure-HTTP, which includes denying new features from sites that are served over HTTP connections. I believe that is a mistake.
I tweeted about it, but a longer form is in order, so here goes.
# Why HTTPS everywhere is important
Let me start by saying that I strongly believe that the Web should move to HTTPS, and serving content over plain-text HTTP is a mistake. (And yes, this blog is still over HTTP. Apologies. A bug to be fixed soon. Not ironic though.)
Now, why do I think HTTPS is a must?
Well, even if you don't think your content is worth securing for the sake of your users (AKA "so someone will know they browsed my nyan cat collection. Big deal"), not serving it over HTTPS opens your users to various risks. An attacker (which may be their ISP or local coffee shop wifi) can inject their own ads, poison your user's cache or just serve them with the wrong information.
On top of that, if your site includes any form of login, the user's credentials can be stolen by anyone on their network. Anyone.
So, I believe that eventual deprecation of HTTP and forcing HTTPS everywhere is a Good Thing™.
What don't I like about Mozilla's plan, then?
# "Deprecating insecure HTTP" != "HTTPS everywhere"
Mozilla are pushing for something called "opportunistic encryption" as a replacement for insecure-HTTP. The problem is that opportunistic encryption is a misleading name, but I get why it was picked. "Easily circumvented HTTPS" doesn't quite have the same ring to it.
What is this "opportunistic encryption", you ask? Well, In order for you to be certain that the encrypted TLS connection you established is with the server you think you established it with, the TLS connection keys are signed by a certificate, which is guarantied to be issued only by the entity you think you're talking to. So a signed certificate means your encrypted connection goes all the way through to the origin server.
With "opportunistic encryption" OTOH, the certificate can be self-signed, which means that there are no guaranties regarding who signed it, and the encrypted connection can be terminated by any router along the way. In other words, there's no guarantied end-to-end encryption, and intercepting, looking into and changing packets being sent to the user is trivial.
Since network operators are not afraid to perform downgrade attacks, there's no reason to believe this neutered form of TLS will stop the bad actors among them from actively intercepting the user's traffic and changing it, in order to add their own ads, super-cookies or worse.
The only promise of "opportunistic encryption" is that passive attacks would be more difficult (but not impossible).
Yet, Mozilla are pushing for that as a "cheap" replacement for HTTP, on the expense of actually secure HTTPS.
# Free certs!!!
One more reason why certificate cost is soon to be a non-issue is an extremely cool new initiative called "Let's encrypt", that would provide free and easy to install certificates to anyone.
That initiative, driven by both Mozilla and Akamai, will make the "opportunistic encryption" approach even less relevant.
(Disclaimer: I work for Akamai. I'm also not involved in the Let's Encrypt effort in any way)
# Applying pressure in the wrong place
Now going back to Mozilla's deprecation plans, the part that I dislike the most is denying new features from HTTP sites, regardless of the features' security sensitivity.
The Chrome security team have long restricted new security-sensitive (AKA "powerful") features to HTTPS only. The most famous case is Service Workers.
It has arguably hurt adoption of those features, but serving these feature over HTTP would have meant significantly compromising the users' security. The limitation to HTTPS in these cases had real, security-based reasons.
Mozilla's proposal is significantly different. Mozilla wants to limit all new features, with the hope that developers would then fall in line and implement HTTPS on their sites.
In my view this type of thinking shows a lack of understanding why developers haven't moved to HTTPS yet.
Switching a large site to HTTPS requires a lot of work and can cost a lot of money. It may require time investment from developers that management needs to approve. That same management often doesn't care about new browser features, and disabling new features on HTTP is not likely to make a huge impact on their decisions.
So, in order to justify dedicating time and efforts into moving to HTTPS, you need to convince the business people that this is the right thing to do from a business perspective (i.e. that it would cost them real-life money long-term if they won't switch). Unfortunately, keeping the users safe is not always a convincing argument.
Having free certificates is awesome for the long tail of independent developers, but for large sites, that's hardly the main issue.
From what I hear, in many cases there's also another blocker. Many sites include business-essential 3rd party widgets, often ads. If these widgets cannot be served over HTTPS, that's a big issue preventing serving the entire site over HTTPS.
Since you cannot mix HTTP content inside you HTTPS site (for good reason, the chain is as strong as its weakest link), such a site cannot move to HTTPS without suffering mixed-content blocking (or warnings, in the best case).
# What would may work
We've established that we need to convince the business folks, rather than the developers. So, how can we do that?
The first and obvious way is SEO. Google have announced last August that with all other things being equal, HTTPS sites will get higher search ranking than HTTP sites. Since SEO is language that business folks understand well, I think that this is a good first step in motivating businesses to move to HTTPS. The next step would be to increase the importance of that ranking signal, and penalize HTTP sites' ranking.
Next, Mozilla's Henri Sivonen had an interesting idea: limit cookie persistency over HTTP, rather than keeping innocent features hostage. While I'm not 100% certain this won't have side-effects on unsuspecting Web developers, and won't render some currently working legitimate use cases worthless over HTTP, that method does apply pressure in the right place.
3rd party widgets often rely on cookie persistency in order to
# In conclusion
Moving the Web to HTTPS is important in order to keep our users safe and maintain their long term trust in the Web. The way to do that is by convincing the business folks that they have to.
So, while HTTPS everywhere is a noble goal, denying new features from HTTP will only alienate developers and hamper new feature adoption without doing much to convince the people that need convincing.
Update:
In the comments, Patrick McManus clarified that Mozilla does not plan to consider opportunistic encryption as a secure context. Therefore, as part of the deprecation plan, new features will be denied from "opportunistically encrypted" sites as well as regular HTTP sites.
I guess my misunderstanding stems from the term "insecure HTTP", which I assumed means that opportunistic encryption would be considered "secure HTTP". But you know what they say about assuming. So I was wrong about that and I apologize.
I still think opportunistic encryption is a bad idea that will at best be a distraction on our way to securing the Web, but apparently it is not related to Mozilla's deprecation plans.
13 comments
Damien Jubeau — Mon, 11 May 2015 14:54:21 GMT
Great post! I totally agree about SEO probably being the easiest way to convince business folks. It already started with last year announcement, but for most it was not strong enough (in our reports on www.dareboost.com we advice our user to consider using HTTPs, and we frequently have comments about HTTPs being without effects on SEO... even for users knowing about the announcement. )
@Michael_Martinez — Mon, 11 May 2015 18:00:24 GMT
"An attacker (which may be their ISP or local coffee shop wifi) can inject their own ads, poison your user’s cache or just serve them with the wrong information."
If the Web were magically converted to use HTTPS today all that could still happen because mixed content allows it to happen. HTTPS has a long way to go before it can protect consumers this way.
And it may never happen because people add new layers of concepts to the Web all the time. How is HTTPS going to protect consumers from app development toolkits that insert backdoors into the code for advertisers?
As for the user login experience, I agree that encrypting the transmissions is important but the message from the HTTPS advocates is inadequate. User credentials are unencrypted or re-encrypted with poor technology after they are received by millions of Websites. The message needs to be changed to say "HTTPS is only guarding your data part of the time. Other things need to happen on these Websites, too."
And then, of course, all that will be rendered moot in a few years by passive listening technologies anyway. It won't matter how well the encryption works when everything we type into a computer is interpreted as we type, and when the encryption algorithms are monitored as they encrypt data.
HTTPS has grey hair and privacy advocates are falling behind the curve on this issue. It is nowhere near as cut-and-dried as "everything is better when the whole Web is running on HTTPS." That is just wishful thinking.
Patrick McManus — Tue, 12 May 2015 15:59:03 GMT
You're mistakenly conflating OE with deprecating insecure HTTP.
OE is considered insecure http for all the reasons you point out. OE is simply a better insecure HTTP than plaintext is; but its still insecure. But insecure HTTP is going to be with us for a long time in some form, so we want to use the better variant when it is used.
The deprecating plan says, as first step, new web facing features will require a secure context. Basically secure context means https://.. I think it might also allow http://localhost (not 100% sure), but it doesn't mean OE. This step doesn't ban the use of http:// for other legacy content, so if it is used we'll allow the OE bonus if plaintext is the alternative. You don't get any credit in the web-level security model (i.e. secure context) for that though.
Someday it may be possible that no insecure http would be allowed - that would also be the end of OE. Sadly, that day is a long way down the road. So this is really about https everywhere - which you don't seem to like either - but just a point of clarification.
hth.
Denis Denisov — Tue, 12 May 2015 17:20:00 GMT
I suppose Yoav Weiss receives funding from NSA, CA and Government.
Certification authority may become bankrupt after all (https://letsencrypt.org).