Issue #9424 has been updated by Dirkjan Bussink.


Yusuke Endoh wrote:

> Please give us not only words but also a concrete plan.  

As said in the original mailing list, I'm more than willing to maintain this list for Ruby. 

> The matter is how we determine what is "secure".

> * The authority that suggests a good configuration.  NIST?  NESSIE?  CRYPTREC?  Or what?  I'm not sure.

Actually OpenSSL already provides information on this. They already classify ciphers in categories like LOW, MEDIUM and HIGH. Currently there is no reason to use LOW anymore, but that is still enabled in the OpenSSL defaults. A fix would mean basically just use these classifications and make Ruby only use MEDIUM and HIGH out of the box.

There are plenty of tools these days available that give trustworthy recommendations such as https://www.ssllabs.com/ which has a best practices guide at https://www.ssllabs.com/projects/best-practices/index.html and also Jeff's new project https://www.howsmyssl.com/. These already provide more than enough information to have enough information to make the best decision possible right now on this issue.

These good defaults might change, because new attacks are found and papers are published on these topics. This information finds there way quick as well to these websites and other best practices for SSL deployments. I feel that for this specific decision about default ciphers there is plenty of information publicly available through the channels that a good choice can be made. I'm not at all stating that such a clear solution would apply for every problem ever in OpenSSL, just that this specific problem is a known problem and has a known solution.

> * A trusted, motivated, and expert committer(s) who can interpret and implement the suggested configuration into Ruby OpenSSL.
> * Preparation to continue following the changes of the configuration.

On both these accounts I again volunteer myself. I already work on the GitHub.com SSL deployment and keep an eye on these topics for this reason and also because I care about security. In cases where there is no consensus on what is a good approach to tackle problems, I will reach out to other people with more knowledge. This also means keeping an eye on what other languages like Python and PHP are doing and how they come to their decisions. In this case these are the decisions made:

http://bugs.python.org/issue13636

Which led to weak ciphers being disabled:
http://hg.python.org/cpython/rev/f9122975fd80

Also PHP made decisions like disabling compression:

https://github.com/php/php-src/commit/4a01ddfb5569da1b87dd4cac95c3f709fb607396

Again, I agree that making security decisions is hard. I also think however that in this context each situation is different. This is why I believe general view of "we don't know" can't be generally applied. In this specific case the consensus on what secure defaults are is very clear so therefore I don't see any problems with applying the solution in this specific case.

So given my statements above, this is a description of how I would have handled this issue in this role:

- After the initial report of Jeff Hodges, review what recommendations from others are. What do deployment guides say for example about these ciphers. What is documented on weak ciphers? Discern the consensus here.
- This would have led to the conclusion that there is a broad consensus on this topic and there is currently no good reason to support weak ciphers by default.
- Review what other languages / environments have done in this area. Seeing languages like Python etc. changed this only strengthens the decision making this change.
- In this case apply the proposed patch and backport it to maintained Ruby versions, cooperating with the appropriate people here. 

I'm still willing to do this work now and help people out here in applying the suggested patch. I hope you are able to accept my offer to help out so that we can improve the security of Ruby and keep it up to date in the future. 

-- 
Regards,

Dirkjan Bussink

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

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


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