
Bug #9424: ruby 1.9 & 2.x has insecure SSL/TLS client defaults - mikeevans
https://bugs.ruby-lang.org/issues/9424
======
steveklabnik
There's been a lot of anger around Twitter on this. I've also seen a lot of
people cherry-picking a non-native speaker's words out of context too.
Specifically, "Ruby is not a project for security."

That doesn't mean that this bug is not important, or that the Ruby team's
decision as it currently stands is a good one. But it's a complex issue.

~~~
coherentpony
If someone gave me that sentence, I wouldn't know whether the person that
wrote it was a native speaker or not.

~~~
steveklabnik
Exactly. And it implies something different than what was meant if you read
the surrounding context.

------
state_machine
"Ruby is not a project for security."

That's from ruby-core. That's a frightening attitude for a project to take.

~~~
dperfect
Did you actually read the context of that quote, which happens to communicate
almost exactly the opposite of what you're inferring (and implying by quoting
it out of context)?

~~~
state_machine
Sure, the context of the thread is that ruby-core is reluctant to start
changing OpenSSL defaults because Security is Hard, the ruby team is
volunteers who might not have expert-level crypto understanding, and and you
risk doing more harm than good if you mess with crypto when you do not know
what you're doing, so they'd rather leave OpenSSL's defaults alone, and let
OpenSSL, written and reviewed by security focused people, fix any issues (I
think this is a fair summary?).

While these are valid concerns, you can't wholly pass the buck to OpenSSL and
to people installing a new version of OpenSSL and re-linking ruby against that
-- ruby project should should always ship the most secure ruby possible, all
the time.

Newer OpenSSL has already changed these defaults, smart people who know what
they are doing have already agreed and documented that this is a good idea,
and ruby is only hurting their users by dodging responsibility.

edit: spelling.

~~~
dperfect
Yes, I agree - the ruby project should always ship the most secure ruby
possible, all the time.

Would you rather have a ruby-core of honest, hardworking developers who prefer
to "delegate the task to other people" who are experts in security - because
they admit their own weaknesses, or a ruby-core of arrogant developers who
overstep their area of expertise just to try and deliver your "most secure
ruby possible" \- but more than likely worsening security?

It sounds to me like they're doing the most responsible thing they possibly
can given the circumstances. If you or anyone else is in a position to do
better, then by all means, step up and bless the ruby world with your supreme
intellect.

admitting weakness + asking for help != dodging responsibility

~~~
kingkilr
Let us present a third possibility: Maybe they shouldn't have shipped a TLS
client if they weren't prepared to take responsibility for how it was
configured.

~~~
dperfect
True, and by that same logic maybe anyone using ruby's TLS client shouldn't
ship anything if they aren't prepared to take responsibility for how it's
configured (since the default configuration can be overridden at any point
from OpenSSL on up).

~~~
kingkilr
Sure, any consumer of this API really should fix it themselves to have a
secure configuration. But I submit that basically none of them are. An API
where almost everyone who uses it wrong is not a good API. When the
consequence of using it wrong is poor security, that's a dangerous API.

Knowingly shipping dangerous APIs is irresponsible.

OpenSSL is a god damned shitshow, no questions from me, it's bad, it's
dangerous, it's irresponsible.

But they shipped something based on OpenSSL, and now they're making a
deliberate decision not to act to protect their users. That's not cool, and
that's unacceptable to me. If I actually used Ruby, this would make me
reconsider that.

~~~
donaldstufft
Importantly, every layer in the stack is responsible for it's own security. A
consumer of this API _should_ be making sure that it's optimally configured
and configure it differently where it's not. Any project that isn't doing that
should have security reports sent to it to tell it to do that and if they
refuse they are guilty of the same sort of negligence as ruby core.

However the fact that other people should also be claiming responsibility for
their own security does not absolve ruby of it's own responsibilities.

------
ces1
Non-SSL expert here and first time poster (not trolling). Python also uses a
wrapper for OpenSSL and has similar issues with default settings. Is this
problem specific to Ruby or also Python apps as well?

~~~
sanxiyn
This also applies to Python. For example, Python recently disabled SSLv2.
Someone filed a bug and the fix was committed within 3 hours.
[http://bugs.python.org/issue20207](http://bugs.python.org/issue20207)

------
tptacek
The SSL2 ClientHello thing is, IIRC, also a compat hack; Firefox used it (at
least until recently) when it connected through proxies.

~~~
briansmith
Firefox stopped using it on 2011-08-16. If you've seen Firefox using it
recently when connecting through proxies, please let me know.

~~~
tptacek
I'm sure you're right. It was on whatever version of Firefox was on my work
laptop the week I learned Golang, since my first project with the language was
an HTTPS/SSL proxy. I even griped about it on Twitter (it breaks Golang's
crypto/tls), and (after we'd hacked support for it into our local tree) got a
link to a patch. That would have been... meh... a year and a half two years
ago.

------
lobster_johnson
Anyone know of a simple recipe to set up secure defaults?

~~~
pixl97
This is a good place to start on good OpenSSL defaults.

[https://www.ssllabs.com/projects/best-
practices/index.html](https://www.ssllabs.com/projects/best-
practices/index.html)

------
girvo
So does PHP, though this is fixed in 5.5 IIRC.

