Is Secret Sharing for Convenience Really Keeping a Secret?

I grew up with the maxim “security by obscurity bad, real security good” ringing in my head.

That’s why I find it so hard to be amused when I hear arguments that obscurity can provide security if it is more “convenient.” And then I see products that actually embrace security-by-obscurity-for-convenience out there in the market – and being shipped by companies claiming to be security vendors.

This has come up recently in the context of captive portal login certificate warnings. The beauty of captive portal is that it uses a standard Web browser as a nice GUI for someone logging in. Since it talks to a more or less standard Web server, the way to secure passwords sent over the link is to use TLS. But to use TLS, the server needs a public key certificate, and browsers want (or, should want) to verify the names in these certificates and who issued them, mostly for Web commerce but in this case to protect against password sniffing or classic spoofing attacks.

Many products provide a throw-away temporary certificate for evaluation purposes. This almost always is a self-signed certificate so that customer’s passwords are at least encrypted using a new private key for that deployment. But this gives a browser warning about the certificate not having been issued by a known CA.

So some products try to avoid this major inconvenience by using HTTP as the default. Since this is clearly insecure and most customers will want to turn on TLS, these vendors oblige by shipping a “free” certificate. This way customers don’t get the nasty warning and will see the padlock (if they care), and on newer browsers don’t see red backgrounds in their URLs. End of story, security restored.

Unfortunately, it isn’t. These products get rid of the warning by using a vendor public domain name and baking the same certificate into their software. That means everybody has the same private key, too. How many of these customers actually click on the browser padlock and view the name in the certificate? Do you do this when you go to your bank or order on Amazon? Unfortunately, too many people aren’t in the habit.

I was taught that a secret shared with everyone is not a secret at all. If you’re going to provide a security mechanism, do it right – make it clear that what’s shipped by default is strictly for evaluation and let people put in their own real certificate.

That is, if they care about security in the security product they are purchasing. Isn’t that the whole point?

Comments

[ashimmy]

Good point Dom. We ran into this problem in a big way with the DoD. They have a central certificate authority and it is not easy to get certs issued. It can be troublesome, but if you want to do it right, that is the way to do it. However, with security it is always about weighing convenience versus security.