Why I need a browser that's willing to accept bad TLS certificates

November 17, 2014

One of my peculiarities is that I absolutely need a browser that's willing to accept 'bad' TLS certificates, probably for all species of bad that you can imagine: mismatched host names, expired certificates, self-signed or signed by an unknown certificate authority, or some combination of these. There are not so much two reasons for this as two levels of the explanation.

The direct reason is easy to state: lights out management processors. Any decent one supports HTTPS (and you really want to use it), but we absolutely cannot give them real TLS certificates because they all live on internal domain names and we're not going to change that. Even if we could get proper TLS certificates for them somehow, the cost is prohibitive since we have a fair number of LOMs.

(Our ability to get free certificates has gone away for complicated reasons.)

But in theory there's a workaround for that. We could create our own certificate authority, add it as a trust root, and then issue our own properly signed LOM certificates (all our LOMs accept us giving them new certificates). This would reduce the problem to doing an initial certificate load in some hacked up environment that accepted the LOMs out-of-box bad certificate (or using another interface for it, if and where one exists).

The problem with this is that as far as I know, certificate authorities are too powerful. Our new LOM certificate authority should only be trusted for hosts in a very specific internal domain, but I don't believe there's any way to tell browsers to actually enforce that and refuse to accept TLS certificates it signs for any other domain. That makes it a loaded gun that we would have to guard exceedingly carefully, since it could be used to MITM any of our browsers for any or almost any HTTPS site we visit, even ones that have nothing to do with our LOMs. And I'm not willing to take that sort of a risk or try to run an internal CA that securely (partly because it would be a huge pain in practice).

So that's the indirect reason: certificate authorities are too powerful, so powerful that we can't safely use one for a limited purpose in a browser.

(I admit that we might not go to the bother of making our own CA and certificates even if we could, but at least it would be a realistic possibility and people could frown at us for not doing so.)


Comments on this page:

By Andrew at 2014-11-18 17:14:41:

So you're choosing to compromise your own security because you can't trust the people who would administrate the CA?

I think you want a name constraint extension on your internal CA: http://tools.ietf.org/html/rfc5280#section-4.2.1.10

How about using a separate Firefox profile for this? If your internal CA's root certificate is only installed in a profile that's specifically for accessing LOM interfaces, then it won't affect regular browsing for you.

Similarly, you can set up another profile with more permissive (i.e. unsafe!) SSL settings for doing the initial setup...

By cks at 2014-11-18 19:43:07:

Andrew: yes, where 'the people who would administer the CA' are 'us'. I don't want to be responsible for that sort of loaded gun, especially when it's pointed at my own feet.

As for separate profiles: I'm not sure that all browsers that we'd want or need to use (on all systems) support separate profiles with separate CAs. Beyond that there are issues of user annoyance in various ways.

The name constraint extension is an interesting approach, assuming it actually works in browsers. On the other hand, Mozilla's developer documentation on certificates does talk about it explicitly.

(In practice it's also hard to get very motivated about this. If someone can MITM one of our connections to a LOM we already have severe problems because they're manipulating routing or shimming in physical hardware inside what is supposed to be a secure network environment and machine room. It's not like we expose these things to the Internet.)

Written on 17 November 2014.
« We've started to decommission our Solaris 10 fileservers
Finding free numbers in a range, crudely, with Unix tools »

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

Last modified: Mon Nov 17 23:11:39 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.