Security is everyone's job (why Ruby is wrong about OpenSSL)

January 22, 2014

The short version of the Ruby controversy of the day is here. The really short version is that the Ruby core has bindings for OpenSSL, some versions of OpenSSL have defaults that are terrible for security, and the Ruby core developers have decided that they will not change the Ruby bindings to fix these terrible defaults. Instead they are simply washing their hands of the issue and making security the responsibility of users of the bindings (and OpenSSL).

The Ruby core developers are wrong. Security is everyone's job, all the way up and down the stack. If someone below you screws up, it is your job to fix this for your users. By rejecting this the Ruby developers have chosen mathematics instead of people, whether they understand it or not.

I don't say this as a matter of high-minded principles. I say this as a matter of pragmatic engineering because we already know what happens if we don't do this. If you leave security problems exposed by default, some number of your users will do nothing to fix them for various reasons and will themselves be insecure. Often this will be a reasonably large number of your users. If you actually care about security, this is a clearly bad thing. Conversely if you engineer things right and hide security problems by default, many of your users will use your defaults and be secure. The golden rule is that many of your users will never touch your defaults unless they clearly don't work, so they will get whatever security you left them by default.

(Nor is this a novel principle. We've experienced it over and over, across almost every conceivable environment, and not just in the context of security but the context of every single default ever. We know this.)

At this point in time, 'insecure by default' is plain and simply wrong. The inevitable and entirely predictable result of shipping an insecure by default layer is a raft of future downstream security updates as plenty of downstream developers have to individually make the fix that you could have done once, for all of them. Oh, and their software was vulnerable in the mean time.

(And if you argue that your downstream developers should all be smarter than that, as usual you are not solving the real problem. Security is people.)

Written on 22 January 2014.
« Fake versus real metaclasses and what a fully functional metaclass is
Microsoft has become a spam emitter »

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

Last modified: Wed Jan 22 00:47:13 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.