The browser security dilemma

May 30, 2016

So Pete Zaitcev ran into the failure mode of modern browsers being strict about security, which is that the browser locks you out of something that you need to access. The only thing I'm much surprised about is that it happened to Pete Zaitcev before it happened to me. On the one hand, this is really frustrating when it happens to you; on the other hand, the browsers are caught on the horns of a real security dilemma here.

To simplify, there are two sorts of browser users; let us call them sysadmins and ordinary people. Sysadmins both know what they're doing and deal with broken cryptography things on a not infrequent basis, such as device management websites that only support terribly outdated cryptography (say SSLv3 only), or have only weak certificates or keys (512 bytes only, yes really), or their certificate has long since expired and are for the wrong name anyways. As a result, sysadmins both want ways to override TLS failures and can (in theory) be trusted to use them safely. By contrast, ordinary people both don't normally encounter broken cryptography and don't really know enough to handle it safely if they do.

In an ideal world, a browser would be able to tell which sort of person you were and give you an appropriate interface. In this less than ideal world, what browser vendors have discovered is that if you expose a 'sysadmin' interface in basically any way, ordinary people will eventually wind up using it for TLS failures that they definitely should not override. It doesn't matter how well you hide it; sooner or later someone will find it and write it up on the Internet and search engines will index it and people will search for it and navigate the ten steps necessary to enable it (and ignore your scary warnings in the process). If we have learned anything, we've learned that people are extremely motivated to get to their websites and are willing to jump through all sorts of hoops to do so. Even when this is a terrible idea.

Since ordinary people vastly outnumber sysadmins, browsers are increasingly opting to throw sysadmins under the bus (ie, completely not supporting our need to override these checks some of the time). At the moment, some major browsers are less strict than others, but I suspect that this will pass and sooner or later Chrome too will give me and Pete Zaitcev no option here. Maybe we'll still be able to rely on more obscure things (on Linux) like Konqueror, at least if they're functional enough to handle the device management websites and IPMIs and so on that I need to deal with.

(Failing that, there may come a day where I keep around an ancient copy of Firefox to handle such sites, in just the same way that I keep around an ancient copy of Java to deal with various Java based 'KVM over IP' IPMI things. Don't worry, my ancient Java isn't wired up as an applet and only works in a non-default browser setup in the first place.)


Comments on this page:

By Ewen McNeill at 2016-05-31 02:00:25:

FWIW, that specific instance seems to also involve a HSTS policy, and it seems to be the HSTS policy that is causing Firefox to refuse to allow overrides (ie as instructed by the website policy). Which seems more reasonable than just refusing by default.

That said I do agree that some of these things want a "Sysadmin mode". If only because for some devices the only practical way to fix TLS issues is to access them in an insecure manner first. Possibly something involving a command line and typing the phrase "I know this is a really bad idea" would sufficiently discourage casual use...

Ewen

By James (trs80) at 2016-05-31 08:03:39:

And not just users, nefarious actors will use sysadmin interfaces. See eg the reasons for lockdown of Firefox extensions.

Chrome at least will let you bypass (some? all?) SSL errors by typing "badidea"; it has changed at least twice, originally "proceed" and then "danger".

By Tom at 2016-05-31 11:06:49:

One option would be to run a local proxy that presents a secure facade, and connected insucurely to specific resources.

… à la mitmproxy, but purpose-built for upgrading weak crypto, yes.

That was my thought also.

I'm not sure why they can't have an about:config item called something like "DoNotBlameFirefox" (akin to Sendmail's idea).

By cks at 2016-05-31 17:14:53:

David Magda: the moment such an about:config item exists, it will be used by ordinary people to override TLS failures that they shouldn't override. Calling it 'DoNotBlameFirefox' doesn't help because the core goal here isn't avoiding blame, it's making ordinary people more secure.

(And on a more general level, you cannot avoid blame by warning people when you know that people will ignore the warnings. Security is ultimately about people; failing to keep those people secure in the face of predictable events is your failure.)

Written on 30 May 2016.
« 'Command line text editor' is not the same as 'terminal-based text editor'
Understanding the modern view of security »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon May 30 22:58:28 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.