Issue #9424 has been updated by Martin Bosslet.


Yusuke Endoh wrote:
> 
> Emboss, thank you as always with all your great work!
>

Np, thank you!
 
B Kelly wrote:
> Martin.Bosslet / gmail.com wrote:
>  >
>  > Rolling your own defaults is dangerous: Even skilled developers like the
>  > Debian developers can get it wrong sometimes, with disastrous consequences.
>  
>  The Debian blunder has been referenced twice in this discussion, but I think
>  the comparison is not apt.
>  
>  The Debian maintainer _removed lines of code_ from the OpenSSL PRNG
>  implementation. [1]
>  
>  This is hardly in the same category as tightening the defaults to exclude
>  specific ciphers or protocol features already known to be weak or exploitable.
>

And it is. It doesn't matter if you remove something or if you think (!) you are improving the situation. The final patch we all agree on might be perfect. It might also be broken. The problem is that it is our custom patch. Things like this need to be dealt with in one spot and one spot only. It's taken for granted in every other aspect of software development that DRY is the way to go. Yet somehow when it comes to security, it shall suddenly be better for everyone to do their own thing? Take certificate validation for example. It's also more or less broken by default in OpenSSL. To get it right, a lot of projects depending on OpenSSL implemented their own certificate validation code. Because it's a highly non-trivial job, the result is: Many different implementations, many of them incorrect, not secure, not by the book/RFC. It's this kind of proliferation that hurts security in general much, much more in the end. 

>  
>  > It hurts even more that in such cases everyone will start pointing fingers,
>  > asking: "Why didn't you stick to the library defaults???"
>  
>  As opposed to asking: "Why didn't you remove known weak ciphers and exploitable
>  protocol features from the defaults when you were warned about them???"
>  

Because it is a very bad idea trying to fix OpenSSL inside of Ruby! We need to ask OpenSSL developers to fix it centrally, so that everyone can benefit from the change.
  
>  > 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 wonder.  In the blacklisting case, we're not required to make guesses about
>  the future.  We're merely switching off already-known weak or exploitable
>  features.
>
>  Whitelisting goes a step further, gambling that what we know today about the
>  subset of defaults considered superior will continue to hold true down the road.
>  
>  It's not clear to me that's better than the more conservative step of simply
>  blacklisting specific defaults already known to be problematic.
>  
>  

Whitelisting is the preferred approach. Because at every point, you know what you're dealing with [1]. Take SHA-3 for example. If by surprise, it turns out to be severely broken, a blacklist defined today will happily accept SHA-3 in the future because we didn't know better today. Of course we need to adapt the whitelist, too, once it turns out that one of the whitelisted algorithms gets broken. Or if new algorithms are developed that are considered superior. Still, it's always easier to reason about a finite set of algorithms than about a probably unbounded complementary set. Things get even more complicated in our case because the blacklist result is potentially affected by changes in OpenSSL itself. A whitelist would not be affected by external influences.

Having said that, the proposed patch still includes some form of blacklisting. I will get rid of it and make it a pure whitelist, just listing the algorithms one by one.

[1] http://www.testingsecurity.com/whitelists_vs_blacklists

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

* 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/