From: shyouhei@... Date: 2014-01-22T06:45:41+00:00 Subject: [ruby-core:59964] [ruby-trunk - Bug #9424] ruby 1.9 & 2.x has insecure SSL/TLS client defaults Issue #9424 has been updated by Shyouhei Urabe. Samuel Leslie wrote: > Nobuyoshi Nakada wrote: > > Why won't they upgrade OpenSSL, but only Ruby? > > OpenSSL on effectively all mainstream/general-purpose distributions tends to be a core system library which many applications depend on. This makes upgrading it outside of the standard distribution updating process (via yum, apt, pacman, etc...) decidedly non-trivial and generally ill-advised unless you **really** know what you're doing. The more sane alternative for where the base OpenSSL libraries don't suffice is to compile your application against a custom OpenSSL build instead of using the system provided libraries. This of course means that you have to compile a custom OpenSSL in the first place instead of using distribution provided pre-built packages and is likely to entail some level of extra work on the users part. It's often relatively difficult/complex to do and we shouldn't expect Ruby users to have to go through this process just to get a secure installation. So do ruby. Don't know what OS you're using but the situation doesn't change between OpenSSL and Ruby in vast majority of Linux distributions, maybe also on BSDs. > Nobuyoshi Nakada wrote: > > It's the responsibility of distributors. > > The distributions responsibility only extends to ensuring that the OpenSSL libraries included with the system function as expected and are secure to the extent there are no vulnerabilities in the installed version. Note that what we're discussing here is not a vulnerability due to a flaw in the OpenSSL codebase itself but rather vulnerabilities being potentially exposed due to poor configuration. Many libraries can be misused in a way to result in an insecure configuration and crypto libraries are a particularly prominent case. OpenSSL admittedly makes it easier to do than other libraries due to some particularly strange or outright poor defaults, but there's a long tail of legacy reasons for many of these choices, and ultimately, Ruby as a user of the OpenSSL library should take responsibility for using the library properly. This extends to ensuring we use sane defaults so Ruby users are not exposed to unnecessary risk. Requesting OpenSSL just change these for our benefit is both not going to happen and trying to avoid responsibility. We are amateur about security. It might be possible to change something, then we have no idea what happens with that modification and even worse, we cannot maintain that bit when security research develops and turned out our change was in fact ill. Talking about responsibility, I have to say that providing what we don't understand is worse than just doing nothing. > Nobuyoshi Nakada wrote: > > Then we should reject older versions? > > No, as there would be a huge installed base of users running older OpenSSL versions which aren't technically at fault (in that they aren't inherently broken when used with sane settings). Upgrading these installations is impractical or overly difficult for the reasons noted above alongside the fact the libraries themselves are fine when configured appropriately. OK, fine about this point. > Myron Marston wrote: > >I can't speak for everyone, but speaking for myself: before Jeff raised this issue I had no idea that OpenSSL was something I needed to pay attention to and consider upgrading. > > Which just adds to the importance that the Ruby project take responsibility for overriding any defaults which OpenSSL uses that are either outright insecure or just simply a poor default choice for Ruby. It's completely understandable that Myron wouldn't be aware of the links between Ruby and OpenSSL and I suspect this is true for the vast majority of Ruby users. Expecting that Ruby users who utilise OpenSSL in a direct or indirect way have in-depth knowledge of OpenSSL default settings and their respective security ramifications is absurd. > > It's true that security is hard, that's why Ruby as a respected and prominent programming language needs to ensure that appropriate steps are taken to protect users of the language by ensuring they are not exposed to unnecessary risk via poor security defaults. Security is hard because NO ONE HELPS US BUT JUST COMPLAIN. Fuck off. ---------------------------------------- Bug #9424: ruby 1.9 & 2.x has insecure SSL/TLS client defaults https://bugs.ruby-lang.org/issues/9424#change-44496 * 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/