Secure web? That'll cost you, thanks to Mozilla's HTTPS plan Firefox shop Mozilla recently became the latest in the long line of companies big and small trying to push the web from HTTP to the more secure HTTPS protocol. In the post-Snowden world, where everyone from the NSA, GCHQ to your ISP is inspecting and sometimes altering content, HTTPS (which makes such things nearly impossible …
Indeed, they tried to with pointless GUI changes and "lets copy Chrome" approach to hide and obscure menus and other featured of interest.
Why stop there? Why not also break access to your local router, home NAS, and lots of old but interesting sites which the owners of have died, moved on, or otherwise given up maintenance on?
Really, some developers seem to spend their day in a jerk-circle reassuring each other that they are right and the rest of the world (i.e. the users of their product) are fools for not agreeing.
Well, I tend to agree that it's not a good idea but I also agree that it doesn't break things as badly as has been made out.
As far as I can see old sites won't be effected as they won't use new features anyway, to take one example.
Again, I agree with the article that SSL isn't without cost but I disagree that it's hard to set-up. There are loads of "guides" available on the Web even if your SSL certificate provider doesn't provide you with one.
... is that sites which lurk around, turn up on searches, but which haven't been modified for years and may even be for businessess which are now defunct, should finally disappear completely.
However that's not a good enough reason for Mozilla to try to force this change on everyone just because they can.
"...sites which lurk around, turn up on searches, but which haven't been modified for years and may even be for businessess which are now defunct, should finally disappear completely."
And that is upside how? It just seems to be downside to me.
Sites with information that is years old but valid should not need to be (and should not be) modified. We are not all MIllennials who need shiny!
The National Museum of Computing just issued an appeal for a data-sheet for an old piece of equipment they are trying to restore or emulate or something. Backed up with an offer of a financial reward! So, it is pretty important to them. If the web had been around then, and someone had the information they need on their old website, it would now be valuable.
In which case, there are such things as The Wayback Machine which archive information.
But defunct sites will no longer appear in search results.
@Graham Marsden
and how are you supposed to find vital information that is only on an old website, if it doesn't turn up in searches?
A lot of websites which just give out static information don't need to be encrypted and if it is an old site that is no longer maintained, but is kept going, because it provides important information that is still needed, why should they have to invest in getting it HTTPS compliant? They are offering the information as a public service, just Mozilla has decided that isn't good enough.
It isn't just about businesses with developers, it's about typical users with their own .me domain name hosting their blog about their kitten, they keep up to date with their updates, and their blog has all the HTML5 bells and whistles........... and is blocked from Firefox because they now have to go and get a certificate, install the certificate and, when their certificate is about to expire, renew the certificate or get a huge "this site is dangerous, don't go there" message.
It isn't just about businesses with developers, it's about typical users with their own .me domain name hosting their blog about their kitten
So in your mind, the "typical user" runs and maintains their own VPS, on which they manually install and configure wordpress and apache? And, despite their apparent server-side expertise, they're incapable of adding a few lines to their apache config to enable SSL?
Are you sure the "typical user" won't actually be using a hosted service for their blog, where all the complicated back-end stuff is actually done by a business with developers?
> Are you sure the "typical user" won't actually be using a hosted service for their blog, where all the complicated back-end stuff is actually done by a business with developers?
Quite probably yes.
But, they won't be doing a lot of stuff for free. I have a site which was a blog but which is now pretty static - I've had no reason to update it for some time. I started it <cough> years ago when information on the subject was "closely guarded" by vested interests who didn't want DIYers to know how to do stuff for themselves. Things have changed, information is out there, but a lot of the information - whilst old - is still relevant and useful. I know it gets linked to some of the "how and why to do this" articles from quite a few forum posts.
But, it's hosted with the "free" hosting that comes with my internet package. It's HTTP only, and HTTPS is not offered on the host - as least, not under my domain name. If I want to SSL enable the site I'll have to move it, pay to host it on another site, and probably pay extra for SSL.
Mind you, I might need to move it anyway. The server it is on does have an SSL service running - but not for customer sites. So the "helpful" browsers that try SSL first come up first with a certificate warning, and if that doesn't scare the user away, they get a completely unrelated ISP site.
Extra for the cert itself - even if the hosting provider deal with the technicalities and automates the human cost out of it, there's still the cert cost.
And then there's the extra cost of having a separate IP for it. That is, unless you want to cut off all XP (and earlier)* users from accessing the site. Some may think this is a good thing, personally I don't see that deliberately cutting off a chunk of users just because someone somewhere things it's a good idea to "force" HTTPS on sites where it's not needed is warranted.
* I know that XP and earlier can't access SSL enabled sites using host headers to differentiate between sites. I have no idea what the situation is for other OSs.
And if you're a mom and pop business, with a site set up via a "click this button to deploy your website" service? Which developer is going to be fired? There isn't one. Websites don't all come from developers...
We are even teaching kids how to create their own websites in schools. Are we expecting them to go and pay for SSL certificates too?
I'm terribly sorry but I think I missed the bit where they explain that I shouldn't be visiting sites like http://www.catsthatlooklikehitler.com/ and http://thecatscan.tumblr.com/ because they're not https enabled.
If the site has no personalised content, it's the same for everyone (say wordpress with NO comments enabled), what actually is the point of the HTTPS?
It's horrendously more expensive compared to ordinary shared IP address Linux hosting. Before you even factor the certificate costs.
It means the stuff can't be altered in transit by an ISP or a malicious party. Think Verizon's client ID or the Chinese Cannon. Encrypted EVERYTHING is the most practical way to deal with these kinds of man-in-the-middle alterations, and a TLS-based protocol is the best option we have that's in wide use. Also, HTTPS has the big benefit that it's already in use, unlike Berners-Lee's proposal which is over 15 years old (RFC2817) and requires browser rewrites to support a protocol that doesn't exist yet (which may not be an option for old-but-still-in-use programs).
It gets you lots more than that. Your entire GET request is encrypted. So if you browse the BBC news site at work, currently your boss can track not just your use of the site, but also what stories your interested in. Perhaps you show a sudden interest in cancer stories and so you lose your job in some downsizing just in case you go off on sick leave. With https, all your boss knows is that you spent 20 minutes reading the news.
By hiding the metadata https benefits more than just users of sites that personalize content.
That's only if your corporate overlord pushes their MITM CA certificate to your browser's certificate store. As most browsers use Windows' certificate store this quite easy unless you use Firefox which will kick up a stink as it uses its own certificate store which won't have been meddled with.
"It means the stuff can't be altered in transit by an ISP or a malicious party."
Correction, if someone is currently intercepting your http traffic, they could have already setup a fake certificate authority server. This means, your https traffic is already intercepted. It also does not take in effect the proxy servers around the globe that already intercept https traffic.
Only half-joking...remember how the security enhancements of Windows Vista worked out in practice? A security nag dialog every time you scratched your nose with two results: clicking "go ahead and do your worst" became muscle-memory AND everybody wanted a quieter OS. For some MS users that was iOS or Ubuntu, for many more it was eventually Win7 (greeted like the Second Coming simply for not sucking so hard)
Piss users off enough and they'll even buy a new machine. But in the browser space? A quick non-disruptive download away will be Chrome, IE, Opera even...all eager to import bookmarks and provide hand-holding for the migration.
Another option would be for HTTP to follow the footsteps of FTP and introduce an explicit mode that allows clients to optionally step up to TLS mode over the native port and to allow mixed content.
With FTP-ES, a client connects to a FTP server on port 21 using clear-text. The client can then request to enter secure TLS mode. If the server doesn't support it, the client can abort or continue. Likewise, if the client doesn't support FTP-ES, the server can restrict access. The protocol also allows granular encryption of the control channel, the data channel or both.
In a theoretical HTTP-ES, a new HTTP-4xx code could be introduced that requires clients to step-up to TLS mode. It could require granular encryption of cookies, all headers, payloads or everything. Likewise, clients could automatically request TLS if it is trying to present a secure cookie to the server or if the user prefers it. It could also provide a CRC of the payload in the encrypted portion to guard against MitM tampering.
The benefits of HTTP-ES would be: no broken bookmarks, lower overhead when all you need is cookie or header obfuscation, increased protection against MitM attacks and some compatibility with external cache servers.
"The benefits of HTTP-ES would be: no broken bookmarks, lower overhead when all you need is cookie or header obfuscation, increased protection against MitM attacks and some compatibility with external cache servers."
The big drawback, as some ISPs have shown, is that even this initial handshake can be exploited to man-in-the-middle the connection BEFORE the secure phase can take place. About the only way you can prevent this is to start the connection with the key exchange and don't continue without it being complete; otherwise, that crack in the door is enough to get the proverbial foot in. IOW, don't do ANYTHING in the clear, not even a request to go secure; you MUST go secure from the get-go.
HSTS, certificate pinning, and opportunistic encryption more-or-less implement your idea. Well, opportunistic encryption did implement your idea but it's on hold in Firefox while the bugs are being ironed out.
As for the cost, you can use self-signed certificates with opportunistic encryption without the browser displaying any warning because with OE the important thing is the encryption, not the authentication.
So, unfortunately, the article's premise is completely wrong - the cost is a big fat 0, apart from a slightly increased encryption/decryption load at both the client and server end.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
