Issue #9424 has been updated by Martin Bosslet.

File change_ssl_defaults.diff added

First some words why I (and others here) believe that it's not a good idea to deviate from OpenSSL defaults:

Security is a delicate issue and typically consumers relying on a library like OpenSSL often do so because they don't want to be burdened with low-level decisions. Reasons can be manyfold, lack of domain knowledge, not wanting to take on that responsibility etc. Therefore, at least in my very own opinion, it should be the responsibility of the library itself to keep sane defaults and also to leave as few options as possible remaining for consumers to decide. There should be one central place where these defaults are kept, so anyone knows where to look when trying to analyze or update them. DRY principle and all that. This is why in an ideal world, everybody would rely on OpenSSL's defaults. Rolling your own defaults is dangerous: Even skilled developers like the Debian developers can get it wrong sometimes, with disastrous consequences. It hurts even more that in such cases everyone will start pointing fingers, asking: "Why didn't you stick to the library defaults???" Deviati
 ng from library defaults also comes with the burden that it forces you to keep a close eye on any changes regarding upstream defaults. Even the slightest change might completely break the security of any hand-rolled defaults, e.g. if a new parameter adds a new "dimension" or if the meaning of some existing parameter changed etc. Now you might say that this should be my/our duty anyway, but then I'd like to remind you that most of us work on Ruby in our leisure time and we might be on vacation, too busy with work - hell, even if you're paid to watch those changes it can still happen that you simply miss something.

So obviously there are many reasons against maintaining your own defaults, from a theoretical as well as a practical point of view. But I do also agree that OpenSSL might sometimes react too slowly when it comes to updating their defaults. They might even have good reasons to leave some dubious defaults in there because they have to support a myriad of different platforms and environments. So I guess it's time for a compromise. Here's one I could live with:

I would prefer a whitelisting approach instead of blacklisting as in the patch that was proposed. Blacklisting is never airtight, as it doesn't protect us from future shitty algorithms creeping in. I have prepared the attached patch which basically limits the TLS ciphers to AES in all its combinations that are currently considered secure. It should pass Jeff's test suite and only allows TLS in version 1.0 upwards - I can't see a reason for keeping SSL v3.

@Jeff: Can you confirm this patch passes all your tests (in particular, it no longer allows the v2 handshake upgrade?)

But again, I firmly believe doing this (our own defaults) is a bad idea. That's why I would like anyone who cares about Ruby's security to go the OpenSSL mailing list and ask them to update *their* defaults. That's something that everybody would benefit from, not just Ruby. I also believe that once (if?) OpenSSL defaults have been sanitized we should immediately discard our own custom settings in the following point release. What about Ruby users with old OpenSSL versions? I think it can not and should not be our goal to try to patch security holes in old versions of OpenSSL in Ruby's OpenSSL extension just so that Ruby users are relieved from having to upgrade. The closer we can stick to OpenSSL in Ruby OpenSSL, the better for everyone's security. Keeping your OpenSSL up-to-date is and will be mandatory in order to guarantee a safe-to-use Ruby OpenSSL extension.

----------------------------------------
Bug #9424: ruby 1.9 & 2.x has insecure SSL/TLS client defaults 
https://bugs.ruby-lang.org/issues/9424#change-44506

* Author: Jeff Hodges
* Status: Assigned
* Priority: Normal
* Assignee: Martin Bosslet
* Category: ext/openssl
* Target version: current: 2.2.0
* ruby -v: ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin12]
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
Ruby 1.9, 2.0, and 2.1 use insecure defaults for SSL/TLS client connections. They have inherited or overridden configs that make the OpenSSL-controlled connections insecure. Note: both OpenSSL's and Ruby's defaults in all tested versions are currently insecure. Confirmation of the issues with Ruby's TLS client can be done with the code in [1].

Ruby is using TLS compression by default. This opens Ruby clients to the CRIME attack[2].

Ruby also uses a variety of insecure cipher suites. These cipher suites either use key sizes much smaller than the currently recommended size, making brute forcing a decryption easy, or do not check the veracity of the server's certificate making them susceptible to man-in-the-middle attacks[3][4].

Ruby also appears to allow SSLv2 connections by default. It does so by first trying to connect with a SSLv2 client hello with a higher SSL/TLS version inside of it which allows SSLv2 servers to work. SSLv2 was broken in the 1990s and is considered unsafe.

These issues expose Ruby users to attacks that have been known for many years, and are trivial to discover. These defaults are often build specific, and are not the same across platforms, but are consistently poor (the code in [1] can evaluate the build). A patch from a core developer on the security@ list is attached. However, the patch does not correct the suspect SSLv2 configuration. It is believed that Ruby 1.8 is also a concern, but, since it was obsoleted, it's not been investigated.

A report similar to this was sent to security / ruby-lang.org four days ago. The Ruby core developers have been unable to patch these problems in a timely manner for it for what I and others believe are concerning reasons. This ticket is being made to allow engineers outside of the small group that are on security@ to protect themselves from these attacks.

[1] https://gist.github.com/cscotta/8302049
[2] https://www.howsmyssl.com/s/about.html#tls-compression
[3] https://www.howsmyssl.com/s/about.html#insecure-cipher-suites
[4] TLS_DHE_DSS_WITH_DES_CBC_SHA - small keys
TLS_DHE_RSA_WITH_DES_CBC_SHA - small keys
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - MITM
TLS_ECDH_anon_WITH_AES_128_CBC_SHA - MITM
TLS_ECDH_anon_WITH_AES_256_CBC_SHA - MITM
TLS_ECDH_anon_WITH_RC4_128_SHA - MITM
TLS_RSA_WITH_DES_CBC_SHA - small keys
TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA - MITM
TLS_SRP_SHA_WITH_AES_128_CBC_SHA - MITM
TLS_SRP_SHA_WITH_AES_256_CBC_SHA - MITM

---Files--------------------------------
ruby_ssl.patch (1.08 KB)
change_ssl_defaults.diff (1.24 KB)


-- 
http://bugs.ruby-lang.org/