Issue #9424 has been updated by Shyouhei Urabe.


B Kelly wrote:
> Martin.Bosslet / gmail.com wrote:
>  >  
>  > B Kelly wrote:
>  >>  
>  >>  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?
>  
>  I think we're talking at cross-purposes.  Your arguments focus on what would
>  be ideal: an upstream patch by OpenSSL.  I think nobody disagrees that would be
>  ideal, and presumably most among us are familiar with the downsides of maintaining
>  downstream patches.

Then how can it be legitimate for you to blame Debian people?
I don't wanna be raped like them.

>  >>  > 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!
>  
>  The phrasing seems dramatic.  Are we fixing OpenSSL inside of Ruby?  Or are we
>  adopting a policy for Ruby that stipulates our defaults should favor security over
>  maximum compatibility?
>  
>  
>  > We need to ask OpenSSL developers to fix it centrally, so that everyone can
>  > benefit from the change.
>  
>  Ideally.  Though one can imagine the possibility that OpenSSL may always prefer
>  maximum compatibility by default.  In which case, the Ruby policy might simply
>  differ.

Listen.  I know you want to save the world.  If you are serious
about changing the picture don't care about trivial entities like
Debian or Ruby.  There are literally tens of thousands of wild
applications that use OpenSSL out there and you can't change them
at once.  You have to focus on the real problem to achieve your
goal.  The real problem here is the OpenSSL's providing insecure
menus and slow to fix them.

If you are not interested in securing the world and you want just
to fuck us, it's enough.  Leave here.

>  However, if our position instead is we don't trust upstream at all, and we will
>  be actively maintaining our own whitelist, then sure: whitelist sounds good.

Stop using untrusted upstream.  Now.  Just fix it.

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

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