Skip to content

Instantly share code, notes, and snippets.

@jmhodges

jmhodges/gist:d6480f5f81f25b0dfa15 Secret

Last active January 3, 2016 14:39
Show Gist options
  • Star 12 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save jmhodges/d6480f5f81f25b0dfa15 to your computer and use it in GitHub Desktop.
Save jmhodges/d6480f5f81f25b0dfa15 to your computer and use it in GitHub Desktop.
Download ZIP
This email thread is from security@ruby-lang.org about Ruby's SSL/TLS client insecurity. The output of this was https://bugs.ruby-lang.org/issues/9424
Raw
gistfile1.txt
Subject: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: security@ruby-lang.org
Date: Sun, 12 Jan 2014 18:21:10 -0800
Given ordinary code[1] on OS X 10.8 (at least), Ruby 1.9-p374 and 2.1
defaults to enabling TLS compression making it susceptible to the CRIME
attack[2].
Ruby 1.9-p374 and 2.1 also use a variety of insecure cipher suites. These
cipher suites either use key sizes much smaller than the currently
recommended 128-bits or do not check the veracity of the server's
certificate making them susceptible to man-in-the-middle attacks[3][4].
Reproducing these settings can be used with the given code in [1].
[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
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: security@ruby-lang.org
Date: Sun, 12 Jan 2014 18:28:03 -0800
For clarity, this is also, of course, true for Ruby 2.0.
On Sun, Jan 12, 2014 at 6:21 PM, Jeff Hodges <jeff@somethingsimilar.com>wrote:
> Given ordinary code[1] on OS X 10.8 (at least), Ruby 1.9-p374 and 2.1
> defaults to enabling TLS compression making it susceptible to the CRIME
> attack[2].
>
> Ruby 1.9-p374 and 2.1 also use a variety of insecure cipher suites. These
> cipher suites either use key sizes much smaller than the currently
> recommended 128-bits or do not check the veracity of the server's
> certificate making them susceptible to man-in-the-middle attacks[3][4].
>
> Reproducing these settings can be used with the given code in [1].
>
> [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
>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Nobuyoshi Nakada <nobu@ruby-lang.org>
To: Jeff Hodges <jeff@somethingsimilar.com>, security@ruby-lang.org
Date: Mon, 13 Jan 2014 11:42:49 +0900
(2014/01/13 11:28), Jeff Hodges wrote:
> For clarity, this is also, of course, true for Ruby 2.0.
>
>
> On Sun, Jan 12, 2014 at 6:21 PM, Jeff Hodges <jeff@somethingsimilar.com>wrote:
>
>> Given ordinary code[1] on OS X 10.8 (at least), Ruby 1.9-p374 and 2.1
>> defaults to enabling TLS compression making it susceptible to the CRIME
>> attack[2].
>>
>> Ruby 1.9-p374 and 2.1 also use a variety of insecure cipher suites. These
>> cipher suites either use key sizes much smaller than the currently
>> recommended 128-bits or do not check the veracity of the server's
>> certificate making them susceptible to man-in-the-middle attacks[3][4].
Thank you for the report.
How is this issue urgent?
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Nobuyoshi Nakada <nobu@ruby-lang.org>
Cc: security@ruby-lang.org
Date: Sun, 12 Jan 2014 18:51:59 -0800
I can provide a public report if you would prefer that.
These are real issues with viable, known-for-many-years attacks against
them.
On Sun, Jan 12, 2014 at 6:42 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
> (2014/01/13 11:28), Jeff Hodges wrote:
> > For clarity, this is also, of course, true for Ruby 2.0.
> >
> >
> > On Sun, Jan 12, 2014 at 6:21 PM, Jeff Hodges <jeff@somethingsimilar.com
> >wrote:
> >
> >> Given ordinary code[1] on OS X 10.8 (at least), Ruby 1.9-p374 and 2.1
> >> defaults to enabling TLS compression making it susceptible to the CRIME
> >> attack[2].
> >>
> >> Ruby 1.9-p374 and 2.1 also use a variety of insecure cipher suites.
> These
> >> cipher suites either use key sizes much smaller than the currently
> >> recommended 128-bits or do not check the veracity of the server's
> >> certificate making them susceptible to man-in-the-middle attacks[3][4].
>
> Thank you for the report.
> How is this issue urgent?
>
>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Nobuyoshi Nakada <nobu@ruby-lang.org>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: security@ruby-lang.org
Date: Mon, 13 Jan 2014 12:13:59 +0900
(2014/01/13 11:51), Jeff Hodges wrote:
> I can provide a public report if you would prefer that.
>
> These are real issues with viable, known-for-many-years attacks against
> them.
Thank you, I see.
And another question, is this a vulnerability in ext/openssl,
not in the underlying TLS library?
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Nobuyoshi Nakada <nobu@ruby-lang.org>
Cc: security@ruby-lang.org
Date: Sun, 12 Jan 2014 19:23:08 -0800
On fairly old OpenSSL implementations (>0.9.8), the defaults include only
some the low key size export ciphers. I believe 0.9.8 disabled TLS
compression, as well. Modern implementations of OpenSSL (~1.0.1e) disable
TLS compression but still include some of the low key size export ciphers.
None of those, to my knowledge, supported the anonymous cipher suites by
default.
I would be surprised if the problem was due to an out of date OpenSSL given
that those Ruby versions are also using TLS 1.2, but perhaps it was patched
oddly.
On Sun, Jan 12, 2014 at 7:13 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
> (2014/01/13 11:51), Jeff Hodges wrote:
> > I can provide a public report if you would prefer that.
> >
> > These are real issues with viable, known-for-many-years attacks against
> > them.
>
> Thank you, I see.
>
> And another question, is this a vulnerability in ext/openssl,
> not in the underlying TLS library?
>
>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Mon, 13 Jan 2014 04:56:02 +0100
In the gist you sent, Net::HTTP uses Ruby's OpenSSL extension, which just
uses the defaults of OpenSSL itself. For example, if I run the gist on my
computer, these are my results:
> ruby -v
ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux]
> ruby -ropenssl -e "puts OpenSSL::OPENSSL_VERSION"
OpenSSL 1.0.1f 6 Jan 2014
> ruby howsmytls.rb
{
"given_cipher_suites": [
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
"TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA",
"TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA",
"TLS_DHE_DSS_WITH_AES_256_GCM_SHA384",
"TLS_DHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA256",
"TLS_DHE_DSS_WITH_AES_256_CBC_SHA256",
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
"TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA",
"TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA",
"TLS_ECDH_anon_WITH_AES_256_CBC_SHA",
"TLS_SRP_SHA_WITH_AES_256_CBC_SHA",
"TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384",
"TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA",
"TLS_RSA_WITH_AES_256_GCM_SHA384",
"TLS_RSA_WITH_AES_256_CBC_SHA256",
"TLS_RSA_WITH_AES_256_CBC_SHA",
"TLS_RSA_WITH_CAMELLIA_256_CBC_SHA",
"TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA",
"TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA",
"TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
"TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA",
"TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA",
"TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA",
"TLS_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
"TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA",
"TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA",
"TLS_DHE_DSS_WITH_AES_128_GCM_SHA256",
"TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_DHE_DSS_WITH_AES_128_CBC_SHA256",
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
"TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
"TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA",
"TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA",
"TLS_ECDH_anon_WITH_AES_128_CBC_SHA",
"TLS_SRP_SHA_WITH_AES_128_CBC_SHA",
"TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDH_RSA_WITH_AES_128_CBC_SHA",
"TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA",
"TLS_RSA_WITH_AES_128_GCM_SHA256",
"TLS_RSA_WITH_AES_128_CBC_SHA256",
"TLS_RSA_WITH_AES_128_CBC_SHA",
"TLS_RSA_WITH_CAMELLIA_128_CBC_SHA",
"TLS_DHE_RSA_WITH_SEED_CBC_SHA",
"TLS_DHE_DSS_WITH_SEED_CBC_SHA",
"TLS_RSA_WITH_SEED_CBC_SHA",
"TLS_RSA_WITH_IDEA_CBC_SHA",
"TLS_ECDHE_RSA_WITH_RC4_128_SHA",
"TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
"TLS_ECDH_anon_WITH_RC4_128_SHA",
"TLS_ECDH_RSA_WITH_RC4_128_SHA",
"TLS_ECDH_ECDSA_WITH_RC4_128_SHA",
"TLS_RSA_WITH_RC4_128_SHA",
"TLS_RSA_WITH_RC4_128_MD5",
"TLS_DHE_RSA_WITH_DES_CBC_SHA",
"TLS_DHE_DSS_WITH_DES_CBC_SHA",
"TLS_RSA_WITH_DES_CBC_SHA",
"TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
],
"ephemeral_keys_supported": true,
"session_ticket_supported": true,
"tls_compression_supported": false,
"unknown_cipher_suite_supported": false,
"beast_vuln": false,
"able_to_detect_n_minus_one_splitting": false,
"insecure_cipher_suites": {
"TLS_DHE_DSS_WITH_DES_CBC_SHA": [
"uses keys smaller than 128 bits in its encryption"
],
"TLS_DHE_RSA_WITH_DES_CBC_SHA": [
"uses keys smaller than 128 bits in its encryption"
],
"TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA": [
"is open to man-in-the-middle attacks because it does not
authenticate the server"
],
"TLS_ECDH_anon_WITH_AES_128_CBC_SHA": [
"is open to man-in-the-middle attacks because it does not
authenticate the server"
],
"TLS_ECDH_anon_WITH_AES_256_CBC_SHA": [
"is open to man-in-the-middle attacks because it does not
authenticate the server"
],
"TLS_ECDH_anon_WITH_RC4_128_SHA": [
"is open to man-in-the-middle attacks because it does not
authenticate the server"
],
"TLS_RSA_WITH_DES_CBC_SHA": [
"uses keys smaller than 128 bits in its encryption"
],
"TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA": [
"is open to man-in-the-middle attacks because it does not
authenticate the server"
],
"TLS_SRP_SHA_WITH_AES_128_CBC_SHA": [
"is open to man-in-the-middle attacks because it does not
authenticate the server"
],
"TLS_SRP_SHA_WITH_AES_256_CBC_SHA": [
"is open to man-in-the-middle attacks because it does not
authenticate the server"
]
},
"tls_version": "TLS 1.2",
"rating": "Bad"
}
In particular: "tls_compression_supported": false
This is just to say that the output does not depend on which Ruby version
you are using but rather on which OpenSSL version it was linked against. In
my case, OpenSSL 1.0.1f already disables TLS compression, but it still
includes the weak ciphers.
As we are using OpenSSL's defaults, we could claim it's their concern to
fix this. However, for BEAST, we did implement our own fix at the time,
before OpenSSL fixed it on their end. But as Ruby OpenSSL is considered to
be just a thin wrapper for the OpenSSL C library, we'd like to avoid custom
code when possible. I'd suggest first asking OpenSSL maintainers if they'd
be willing to fix this on their end, so everyone depending on OpenSSL could
benefit from the fix. You would see the exact same results if you spin up
an http request using the OpenSSL API for TLS sockets directly.
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>
Cc: Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Sun, 12 Jan 2014 20:06:05 -0800
The rubies I have installed are built against a modern OpenSSL, 1.0.1f[1].
As I mentioned before, the only problems in OpenSSL's libraries were the
export cipher suites, but not the anon ones.
Plus, OpenSSL can't correct everyone's already installed versions, so it is
on important clients to fix problems as they can. Python and curl are
already doing this.
This is Ruby's problem, not OpenSSL's
[1]
$ otool -L /opt/local/lib/ruby2.1/2.1.0/x86_64-darwin12/openssl.bundle |
egrep 'lib(ssl|crypto)'
/opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
$ port provides /opt/local/lib/libssl.1.0.0.dylib
/opt/local/lib/libssl.1.0.0.dylib is provided by: openssl
$ port provides /opt/local/lib/libcrypto.1.0.0.dylib
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
$ port installed openssl | grep active
openssl @1.0.1f_0 (active)
Subject: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Nobuyoshi Nakada <nobu@ruby-lang.org>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>, Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Mon, 13 Jan 2014 14:11:40 +0900
Hi,
(2014/01/13 13:06), Jeff Hodges wrote:
> The rubies I have installed are built against a modern OpenSSL, 1.0.1f[1].
> As I mentioned before, the only problems in OpenSSL's libraries were the
> export cipher suites, but not the anon ones.
>
Do you mean that:
(1) OpenSSL already has deprecated and disabled that option by default,
(2) but Ruby's openssl ext enables it?
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Nobuyoshi Nakada <nobu@ruby-lang.org>
Cc: =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>, security <security@ruby-lang.org>
Date: Sun, 12 Jan 2014 21:30:53 -0800
It doesn't matter if OpenSSL has broken defaults or not. Ruby has to own
its security. It's too well-used and too often more easily updated for it
to wait for every library it relies on to fix every broken default.
This is a clear report of very problematic issues and they need correction.
On Sun, Jan 12, 2014 at 9:11 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
> Hi,
>
>
> (2014/01/13 13:06), Jeff Hodges wrote:
>
>> The rubies I have installed are built against a modern OpenSSL,
>> 1.0.1f[1]. As I mentioned before, the only problems in OpenSSL's libraries
>> were the export cipher suites, but not the anon ones.
>>
>
> Do you mean that:
> (1) OpenSSL already has deprecated and disabled that option by default,
> (2) but Ruby's openssl ext enables it?
>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
To: Jeff Hodges <jeff@somethingsimilar.com>
Date: Mon, 13 Jan 2014 07:27:06 +0100
Nobody is saying that your findings are not important! But again, Ruby
OpenSSL follows the defaults set up by OpenSSL itself.
Here is the cipher list you get from OpenSSL (1.0.1f):
#include <openssl/ssl.h>
int main(int argc, char *argv[]) {
SSL_CTX *ctx;
STACK_OF(SSL_CIPHER) *ciphers;
SSL_CIPHER *cipher;
int i, num;
int bits, alg_bits;
SSL_library_init();
SSL_load_error_strings();
ctx = SSL_CTX_new(TLSv1_2_method());
ciphers = ctx->cipher_list;
num = sk_SSL_CIPHER_num(ciphers);
for(i = 0; i < num; i++) {
cipher = sk_SSL_CIPHER_value(ciphers, i);
printf("%s\n", SSL_CIPHER_get_name(cipher));
}
}
It's exactly the same as in Ruby when linked against OpenSSL 1.0.1f:
require 'openssl'
ctx = OpenSSL::SSL::SSLContext.new
ctx.ssl_version = :TLSv1_2
ctx.ciphers.map(&:first).join("\n")
I'm not happy with these defaults either, but it's not very practical to do
a "custom OpenSSL" for Ruby. It can even be dangerous: the Debian bug a
couple of years back demonstrated pretty impressively what might happen if
people start to roll their own OpenSSL. If anyone is unhappy with OpenSSL's
defaults, at least they can configure their SSLContext instance
differently. The options to turn off compression [1] and to use a tighter
set of ciphers [2] are there.
I agree that OpenSSL can't be held accountable for any mistake clients make
with their library. But we are merely using their defaults, and keeping
those sane and safe is obviously in their domain, not ours. I'm not saying
these defaults are less than optimal, though, I'd just like them to be
fixed in OpenSSL itself.
[1]
https://github.com/ruby/ruby/blob/738c298ce0b832edf5bbd2caed662c1e728a2aa8/ext/openssl/ossl_ssl.c#L2265
[2]
https://github.com/ruby/ruby/blob/738c298ce0b832edf5bbd2caed662c1e728a2aa8/ext/openssl/ossl_ssl.c#L876
2014/1/13 Jeff Hodges <jeff@somethingsimilar.com>
> It doesn't matter if OpenSSL has broken defaults or not. Ruby has to own
> its security. It's too well-used and too often more easily updated for it
> to wait for every library it relies on to fix every broken default.
>
> This is a clear report of very problematic issues and they need correction.
>
>
>
> On Sun, Jan 12, 2014 at 9:11 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
>
>> Hi,
>>
>>
>> (2014/01/13 13:06), Jeff Hodges wrote:
>>
>>> The rubies I have installed are built against a modern OpenSSL,
>>> 1.0.1f[1]. As I mentioned before, the only problems in OpenSSL's libraries
>>> were the export cipher suites, but not the anon ones.
>>>
>>
>> Do you mean that:
>> (1) OpenSSL already has deprecated and disabled that option by default,
>> (2) but Ruby's openssl ext enables it?
>>
>>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Mon, 13 Jan 2014 07:27:54 +0100
Nobody is saying that your findings are not important! But again, Ruby
OpenSSL follows the defaults set up by OpenSSL itself.
Here is the cipher list you get from OpenSSL (1.0.1f):
#include <openssl/ssl.h>
int main(int argc, char *argv[]) {
SSL_CTX *ctx;
STACK_OF(SSL_CIPHER) *ciphers;
SSL_CIPHER *cipher;
int i, num;
int bits, alg_bits;
SSL_library_init();
SSL_load_error_strings();
ctx = SSL_CTX_new(TLSv1_2_method());
ciphers = ctx->cipher_list;
num = sk_SSL_CIPHER_num(ciphers);
for(i = 0; i < num; i++) {
cipher = sk_SSL_CIPHER_value(ciphers, i);
printf("%s\n", SSL_CIPHER_get_name(cipher));
}
}
It's exactly the same as in Ruby when linked against OpenSSL 1.0.1f:
require 'openssl'
ctx = OpenSSL::SSL::SSLContext.new
ctx.ssl_version = :TLSv1_2
ctx.ciphers.map(&:first).join("\n")
I'm not happy with these defaults either, but it's not very practical to do
a "custom OpenSSL" for Ruby. It can even be dangerous: the Debian bug a
couple of years back demonstrated pretty impressively what might happen if
people start to roll their own OpenSSL. If anyone is unhappy with OpenSSL's
defaults, at least they can configure their SSLContext instance
differently. The options to turn off compression [1] and to use a tighter
set of ciphers [2] are there.
I agree that OpenSSL can't be held accountable for any mistake clients make
with their library. But we are merely using their defaults, and keeping
those sane and safe is obviously in their domain, not ours. I'm not saying
these defaults are less than optimal, though, I'd just like them to be
fixed in OpenSSL itself.
[1]
https://github.com/ruby/ruby/blob/738c298ce0b832edf5bbd2caed662c1e728a2aa8/ext/openssl/ossl_ssl.c#L2265
[2]
https://github.com/ruby/ruby/blob/738c298ce0b832edf5bbd2caed662c1e728a2aa8/ext/openssl/ossl_ssl.c#L876
2014/1/13 Jeff Hodges <jeff@somethingsimilar.com>
> It doesn't matter if OpenSSL has broken defaults or not. Ruby has to own
> its security. It's too well-used and too often more easily updated for it
> to wait for every library it relies on to fix every broken default.
>
> This is a clear report of very problematic issues and they need correction.
>
>
>
> On Sun, Jan 12, 2014 at 9:11 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
>
>> Hi,
>>
>>
>> (2014/01/13 13:06), Jeff Hodges wrote:
>>
>>> The rubies I have installed are built against a modern OpenSSL,
>>> 1.0.1f[1]. As I mentioned before, the only problems in OpenSSL's libraries
>>> were the export cipher suites, but not the anon ones.
>>>
>>
>> Do you mean that:
>> (1) OpenSSL already has deprecated and disabled that option by default,
>> (2) but Ruby's openssl ext enables it?
>>
>>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>
Cc: Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Sun, 12 Jan 2014 22:35:52 -0800
I have tickets going to improve the OpenSSL defaults. Remember, OpenSSL is
under FIPS compliance rules and it's release process is very, very slow.
The conversation so far has been about OpenSSL, and we've not discussed
what Ruby is going to do.
So, what is Ruby going to do for its defaults?
On Sun, Jan 12, 2014 at 10:27 PM, Martin Boßlet <martin.bosslet@gmail.com>wrote:
> Nobody is saying that your findings are not important! But again, Ruby
> OpenSSL follows the defaults set up by OpenSSL itself.
>
> Here is the cipher list you get from OpenSSL (1.0.1f):
>
> #include <openssl/ssl.h>
>
> int main(int argc, char *argv[]) {
> SSL_CTX *ctx;
> STACK_OF(SSL_CIPHER) *ciphers;
> SSL_CIPHER *cipher;
> int i, num;
> int bits, alg_bits;
>
> SSL_library_init();
> SSL_load_error_strings();
> ctx = SSL_CTX_new(TLSv1_2_method());
>
> ciphers = ctx->cipher_list;
>
> num = sk_SSL_CIPHER_num(ciphers);
> for(i = 0; i < num; i++) {
> cipher = sk_SSL_CIPHER_value(ciphers, i);
> printf("%s\n", SSL_CIPHER_get_name(cipher));
> }
> }
>
> It's exactly the same as in Ruby when linked against OpenSSL 1.0.1f:
>
> require 'openssl'
>
> ctx = OpenSSL::SSL::SSLContext.new
> ctx.ssl_version = :TLSv1_2
> ctx.ciphers.map(&:first).join("\n")
>
>
> I'm not happy with these defaults either, but it's not very practical to
> do a "custom OpenSSL" for Ruby. It can even be dangerous: the Debian bug a
> couple of years back demonstrated pretty impressively what might happen if
> people start to roll their own OpenSSL. If anyone is unhappy with OpenSSL's
> defaults, at least they can configure their SSLContext instance
> differently. The options to turn off compression [1] and to use a tighter
> set of ciphers [2] are there.
>
> I agree that OpenSSL can't be held accountable for any mistake clients
> make with their library. But we are merely using their defaults, and
> keeping those sane and safe is obviously in their domain, not ours. I'm not
> saying these defaults are less than optimal, though, I'd just like them to
> be fixed in OpenSSL itself.
>
> [1]
> https://github.com/ruby/ruby/blob/738c298ce0b832edf5bbd2caed662c1e728a2aa8/ext/openssl/ossl_ssl.c#L2265
> [2]
> https://github.com/ruby/ruby/blob/738c298ce0b832edf5bbd2caed662c1e728a2aa8/ext/openssl/ossl_ssl.c#L876
>
>
> 2014/1/13 Jeff Hodges <jeff@somethingsimilar.com>
>
>> It doesn't matter if OpenSSL has broken defaults or not. Ruby has to own
>> its security. It's too well-used and too often more easily updated for it
>> to wait for every library it relies on to fix every broken default.
>>
>> This is a clear report of very problematic issues and they need
>> correction.
>>
>>
>>
>> On Sun, Jan 12, 2014 at 9:11 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
>>
>>> Hi,
>>>
>>>
>>> (2014/01/13 13:06), Jeff Hodges wrote:
>>>
>>>> The rubies I have installed are built against a modern OpenSSL,
>>>> 1.0.1f[1]. As I mentioned before, the only problems in OpenSSL's libraries
>>>> were the export cipher suites, but not the anon ones.
>>>>
>>>
>>> Do you mean that:
>>> (1) OpenSSL already has deprecated and disabled that option by default,
>>> (2) but Ruby's openssl ext enables it?
>>>
>>>
>>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Nobuyoshi Nakada <nobu@ruby-lang.org>
To: Jeff Hodges <jeff@somethingsimilar.com>, =?UTF-8?B?TWFydGluIEJvw59sZXQ=?= <martin.bosslet@gmail.com>
Cc: security <security@ruby-lang.org>
Date: Mon, 13 Jan 2014 16:22:05 +0900
(2014/01/13 15:35), Jeff Hodges wrote:
> I have tickets going to improve the OpenSSL defaults. Remember, OpenSSL is
> under FIPS compliance rules and it's release process is very, very slow.
OK, I think I understand now.
You say we should make "short-term" workaround for OpenSSL instead of
OpenSSL, correct?
> The conversation so far has been about OpenSSL, and we've not discussed
> what Ruby is going to do.
Because it's an issue of OpenSSL essentially, not Ruby.
> So, what is Ruby going to do for its defaults?
I'm not against providing the workaround, but I have another question.
You called it "known-for-many-years", so how long should we provide
this workaround?
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Nobuyoshi Nakada <nobu@ruby-lang.org>
Cc: =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>, security <security@ruby-lang.org>
Date: Sun, 12 Jan 2014 23:30:04 -0800
This is not a workaround. Ruby will, for the forseeable future, have to
ship with it's own defaults and own them because OpenSSL installations on
its users' machines may have insecure defaults. This is normal, especially
for a project of Ruby's popularity.
On Sun, Jan 12, 2014 at 11:22 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
> (2014/01/13 15:35), Jeff Hodges wrote:
> > I have tickets going to improve the OpenSSL defaults. Remember, OpenSSL
> is
> > under FIPS compliance rules and it's release process is very, very slow.
>
> OK, I think I understand now.
> You say we should make "short-term" workaround for OpenSSL instead of
> OpenSSL, correct?
>
> > The conversation so far has been about OpenSSL, and we've not discussed
> > what Ruby is going to do.
>
> Because it's an issue of OpenSSL essentially, not Ruby.
>
> > So, what is Ruby going to do for its defaults?
>
> I'm not against providing the workaround, but I have another question.
> You called it "known-for-many-years", so how long should we provide
> this workaround?
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Yusuke Endoh <mame@tsg.ne.jp>
To: Nobuyoshi Nakada <nobu@ruby-lang.org>
Cc: Jeff Hodges <jeff@somethingsimilar.com>, security <security@ruby-lang.org>, =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
Date: Mon, 13 Jan 2014 16:34:31 +0900
2014/1/13 Nobuyoshi Nakada <nobu@ruby-lang.org>:
> (1) OpenSSL already has deprecated and disabled that option by default,
In the recent OpenSSL, I think so.
> (2) but Ruby's openssl ext enables it?
No, it does not do so. It just uses the OpenSSL's default settings.
What Jeff is saying is that we should use our own default settings
rather than OpenSSL's default. I don't think it is practical, though.
Note that Net::HTTP provides a user-level workaround already.
http.ciphers = "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2"
will stop the dangerous ciphers, I think.
--
Yusuke Endoh <mame@tsg.ne.jp>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Dirkjan Bussink <d.bussink@gmail.com>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: security <security@ruby-lang.org>
Date: Mon, 13 Jan 2014 08:35:16 +0100
On 13 Jan 2014, at 08:30, Jeff Hodges <jeff@somethingsimilar.com> wrote:
> This is not a workaround. Ruby will, for the forseeable future, have
to ship with it's own defaults and own them because OpenSSL
installations on its users' machines may have insecure defaults. This is
normal, especially for a project of Ruby's popularity.
Strongly agree with Jeff here. It might be idealistically preferred to
have OpenSSL fix their defaults, but actually getting those changes to
end users is going to take years.
Not only will it take a long time for a change to be made in OpenSSL, it
will take even longer for those changes to reach end users due to
package upgrades. OpenSSL is updated far less frequently than Ruby, so
fixing this in Ruby seems to me like a far better solution.
We should consider here the best interest for Ruby users, which is
trying to keep them safe and provide the best secure defaults we can,
regardless of what OpenSSL is doing and how long that is going to take.
—
Regards,
Dirkjan Bussink
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Nobuyoshi Nakada <nobu@ruby-lang.org>
To: Yusuke Endoh <mame@tsg.ne.jp>
Cc: Jeff Hodges <jeff@somethingsimilar.com>, security <security@ruby-lang.org>, =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
Date: Mon, 13 Jan 2014 18:06:56 +0900
(2014/01/13 16:34), Yusuke Endoh wrote:
> Note that Net::HTTP provides a user-level workaround already.
>
> http.ciphers = "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2"
>
> will stop the dangerous ciphers, I think.
Thank you, then this is a patch for this workaround?
diff --git a/ext/openssl/lib/openssl/ssl.rb b/ext/openssl/lib/openssl/ssl.rb
index 014e113..2d4c14d 100644
--- a/ext/openssl/lib/openssl/ssl.rb
+++ b/ext/openssl/lib/openssl/ssl.rb
@@ -20,13 +20,18 @@ require "fcntl"
module OpenSSL
module SSL
class SSLContext
+ options = OpenSSL::SSL::OP_ALL
+ if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
+ options &= ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS
+ end
+ if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
+ options |= OpenSSL::SSL::OP_NO_COMPRESSION
+ end
DEFAULT_PARAMS = {
:ssl_version => "SSLv23",
:verify_mode => OpenSSL::SSL::VERIFY_PEER,
- :ciphers => "ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW",
- :options => defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS) ?
- OpenSSL::SSL::OP_ALL & ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS :
- OpenSSL::SSL::OP_ALL,
+ :ciphers => "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2",
+ :options => options,
}
DEFAULT_CERT_STORE = OpenSSL::X509::Store.new
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Nobuyoshi Nakada <nobu@ruby-lang.org>
Cc: Yusuke Endoh <mame@tsg.ne.jp>, security <security@ruby-lang.org>, =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>
Date: Mon, 13 Jan 2014 10:47:23 -0800
Yep, this changes gets its a Probably Okay.
This patch also explains why folks didn't see ruby having it's own defaults
in the C code.
One weird thing, though, this config claims that Ruby will try to support
SSLv2 first. Is that correct? (I ask because SSLv2 is very broken.)
On Mon, Jan 13, 2014 at 1:06 AM, Nobuyoshi Nakada <nobu@ruby-lang.org>wrote:
> (2014/01/13 16:34), Yusuke Endoh wrote:
> > Note that Net::HTTP provides a user-level workaround already.
> >
> > http.ciphers = "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2"
> >
> > will stop the dangerous ciphers, I think.
>
> Thank you, then this is a patch for this workaround?
>
>
> diff --git a/ext/openssl/lib/openssl/ssl.rb
> b/ext/openssl/lib/openssl/ssl.rb
> index 014e113..2d4c14d 100644
> --- a/ext/openssl/lib/openssl/ssl.rb
> +++ b/ext/openssl/lib/openssl/ssl.rb
> @@ -20,13 +20,18 @@ require "fcntl"
> module OpenSSL
> module SSL
> class SSLContext
> + options = OpenSSL::SSL::OP_ALL
> + if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
> + options &= ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS
> + end
> + if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
> + options |= OpenSSL::SSL::OP_NO_COMPRESSION
> + end
> DEFAULT_PARAMS = {
> :ssl_version => "SSLv23",
> :verify_mode => OpenSSL::SSL::VERIFY_PEER,
> - :ciphers => "ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW",
> - :options =>
> defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS) ?
> - OpenSSL::SSL::OP_ALL &
> ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS :
> - OpenSSL::SSL::OP_ALL,
> + :ciphers => "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2",
> + :options => options,
> }
>
> DEFAULT_CERT_STORE = OpenSSL::X509::Store.new
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Yusuke Endoh <mame@tsg.ne.jp>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>, =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
Date: Tue, 14 Jan 2014 23:04:02 +0900
> This patch also explains why folks didn't see ruby having it's own defaults
> in the C code.
Sorry ;-) But I think this issue suggests precisely the disadvantage
of having the own defaults. It is too hard to maintain.
Anyway, we cannot remove the defaults now for the compatibility. I
agree with the patch. Emboss, what do you think?
2014/1/14 Jeff Hodges <jeff@somethingsimilar.com>:
> Yep, this changes gets its a Probably Okay.
>
> This patch also explains why folks didn't see ruby having it's own defaults
> in the C code.
>
> One weird thing, though, this config claims that Ruby will try to support
> SSLv2 first. Is that correct? (I ask because SSLv2 is very broken.)
>
>
> On Mon, Jan 13, 2014 at 1:06 AM, Nobuyoshi Nakada <nobu@ruby-lang.org>
> wrote:
>>
>> (2014/01/13 16:34), Yusuke Endoh wrote:
>> > Note that Net::HTTP provides a user-level workaround already.
>> >
>> > http.ciphers = "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2"
>> >
>> > will stop the dangerous ciphers, I think.
>>
>> Thank you, then this is a patch for this workaround?
>>
>>
>> diff --git a/ext/openssl/lib/openssl/ssl.rb
>> b/ext/openssl/lib/openssl/ssl.rb
>> index 014e113..2d4c14d 100644
>> --- a/ext/openssl/lib/openssl/ssl.rb
>> +++ b/ext/openssl/lib/openssl/ssl.rb
>> @@ -20,13 +20,18 @@ require "fcntl"
>> module OpenSSL
>> module SSL
>> class SSLContext
>> + options = OpenSSL::SSL::OP_ALL
>> + if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
>> + options &= ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS
>> + end
>> + if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
>> + options |= OpenSSL::SSL::OP_NO_COMPRESSION
>> + end
>> DEFAULT_PARAMS = {
>> :ssl_version => "SSLv23",
>> :verify_mode => OpenSSL::SSL::VERIFY_PEER,
>> - :ciphers => "ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW",
>> - :options =>
>> defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS) ?
>> - OpenSSL::SSL::OP_ALL &
>> ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS :
>> - OpenSSL::SSL::OP_ALL,
>> + :ciphers => "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2",
>> + :options => options,
>> }
>>
>> DEFAULT_CERT_STORE = OpenSSL::X509::Store.new
>
>
--
Yusuke Endoh <mame@tsg.ne.jp>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Yusuke Endoh <mame@tsg.ne.jp>
Cc: Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>, =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>
Date: Tue, 14 Jan 2014 19:30:18 -0800
We will also want to add !SEED:!IDEA there.
So, what's the next steps for the patch?
On Tue, Jan 14, 2014 at 6:04 AM, Yusuke Endoh <mame@tsg.ne.jp> wrote:
> > This patch also explains why folks didn't see ruby having it's own
> defaults
> > in the C code.
>
> Sorry ;-) But I think this issue suggests precisely the disadvantage
> of having the own defaults. It is too hard to maintain.
>
> Anyway, we cannot remove the defaults now for the compatibility. I
> agree with the patch. Emboss, what do you think?
>
>
> 2014/1/14 Jeff Hodges <jeff@somethingsimilar.com>:
> > Yep, this changes gets its a Probably Okay.
> >
> > This patch also explains why folks didn't see ruby having it's own
> defaults
> > in the C code.
> >
> > One weird thing, though, this config claims that Ruby will try to support
> > SSLv2 first. Is that correct? (I ask because SSLv2 is very broken.)
> >
> >
> > On Mon, Jan 13, 2014 at 1:06 AM, Nobuyoshi Nakada <nobu@ruby-lang.org>
> > wrote:
> >>
> >> (2014/01/13 16:34), Yusuke Endoh wrote:
> >> > Note that Net::HTTP provides a user-level workaround already.
> >> >
> >> > http.ciphers = "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2"
> >> >
> >> > will stop the dangerous ciphers, I think.
> >>
> >> Thank you, then this is a patch for this workaround?
> >>
> >>
> >> diff --git a/ext/openssl/lib/openssl/ssl.rb
> >> b/ext/openssl/lib/openssl/ssl.rb
> >> index 014e113..2d4c14d 100644
> >> --- a/ext/openssl/lib/openssl/ssl.rb
> >> +++ b/ext/openssl/lib/openssl/ssl.rb
> >> @@ -20,13 +20,18 @@ require "fcntl"
> >> module OpenSSL
> >> module SSL
> >> class SSLContext
> >> + options = OpenSSL::SSL::OP_ALL
> >> + if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
> >> + options &= ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS
> >> + end
> >> + if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
> >> + options |= OpenSSL::SSL::OP_NO_COMPRESSION
> >> + end
> >> DEFAULT_PARAMS = {
> >> :ssl_version => "SSLv23",
> >> :verify_mode => OpenSSL::SSL::VERIFY_PEER,
> >> - :ciphers =>
> "ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW",
> >> - :options =>
> >> defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS) ?
> >> - OpenSSL::SSL::OP_ALL &
> >> ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS :
> >> - OpenSSL::SSL::OP_ALL,
> >> + :ciphers => "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2",
> >> + :options => options,
> >> }
> >>
> >> DEFAULT_CERT_STORE = OpenSSL::X509::Store.new
> >
> >
>
>
>
> --
> Yusuke Endoh <mame@tsg.ne.jp>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
To: Yusuke Endoh <mame@tsg.ne.jp>
Cc: Jeff Hodges <jeff@somethingsimilar.com>, Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Wed, 15 Jan 2014 08:34:57 +0100
2014/1/14 Yusuke Endoh <mame@tsg.ne.jp>
> > This patch also explains why folks didn't see ruby having it's own
> defaults
> > in the C code.
>
> Sorry ;-) But I think this issue suggests precisely the disadvantage
> of having the own defaults. It is too hard to maintain.
>
> Anyway, we cannot remove the defaults now for the compatibility. I
> agree with the patch. Emboss, what do you think?
>
Personally, I would also prefer if upstream could fix this, if not only for
the sake of DRY.
@Jeff: Have you heard anything from the OpenSSL devs, are they willing to
change their defaults?
If they are not, I understand the arguments for patching this in Ruby
OpenSSL itself. The reason for my concerns is that patching in return means
we'll have to monitor OpenSSL (C library) defaults very closely in the
future. We must adopt any future changes and we must react if they should
change defaults internally altogether. If we miss one of those changes and
a vulnerability evolves from this everybody will point fingers at us for
not sticking to the library defaults.
@Jeff: With the addition of !SEED:!IDEA, you would agree to the patch?
I think it would be a good idea to document each setting, its purpose and
intentions along with the patch. I'd volunteer to do that.
So is everybody for patching this in Ruby OpenSSL? What if OpenSSL devs
decide to patch it on their end, should we still patch it ourselves?
-Martin
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>
Cc: Yusuke Endoh <mame@tsg.ne.jp>, Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Tue, 14 Jan 2014 23:56:56 -0800
I am okay with this patch if Ruby is not using the SSLv2 client hello
format as it seems to be in the configuration. If ruby is using the sslv2
handshake, it needs to be should be bumped up. SSLv2 was broken back in the
90s and this makes users susceptible to downgrade attacks.
Yes, the Ruby developers will have to own this configuration change going
forward. Per earlier discussion, it doesn't matter if OpenSSL changes their
defaults or not, Ruby will have users with insecure OpenSSL libraries
installed. There will always be configurations that OpenSSL or any other
library Ruby needs that will have defaults that will not be safe in Ruby's
security environment and the libraries will have legitimate reasons for
that.
The Ruby developers already should be monitoring for new SSL/TLS attacks
and adjusting to them. Ruby is a popular runtime and its security is the
security of its users. Ruby can't rely on them to have the latest of
everything installed. Look at OS X. The default version of OpenSSL is still
0.9.8 and few ever update it. Users don't even *know* to update it.
Punting problems to the users means that more people have to aware and fix
every single possible issue instead of Ruby providing a safe environment
for them to work in. And those people simply won't do it, either out of
laziness, or ignorance. The Ruby developers are a much better position to
take care of their users.
I note that other runtimes don't have problems owning their security. For
instance, the CRIME attack was well-known and fixed by Java, Go, all of the
major browsers and many others when it was discovered in 2011. The fact
that it was not fixed in Ruby (whether or not they had the latest OpenSSL)
at the same time is a problem with Ruby. Ruby is the unusual one.
I'm very surprised to be having this debate on this email list.
On Tue, Jan 14, 2014 at 11:34 PM, Martin Boßlet <martin.bosslet@gmail.com>wrote:
>
>
>
> 2014/1/14 Yusuke Endoh <mame@tsg.ne.jp>
>
>> > This patch also explains why folks didn't see ruby having it's own
>> defaults
>> > in the C code.
>>
>> Sorry ;-) But I think this issue suggests precisely the disadvantage
>> of having the own defaults. It is too hard to maintain.
>>
>> Anyway, we cannot remove the defaults now for the compatibility. I
>> agree with the patch. Emboss, what do you think?
>>
>
> Personally, I would also prefer if upstream could fix this, if not only
> for the sake of DRY.
>
> @Jeff: Have you heard anything from the OpenSSL devs, are they willing to
> change their defaults?
>
> If they are not, I understand the arguments for patching this in Ruby
> OpenSSL itself. The reason for my concerns is that patching in return means
> we'll have to monitor OpenSSL (C library) defaults very closely in the
> future. We must adopt any future changes and we must react if they should
> change defaults internally altogether. If we miss one of those changes and
> a vulnerability evolves from this everybody will point fingers at us for
> not sticking to the library defaults.
>
> @Jeff: With the addition of !SEED:!IDEA, you would agree to the patch?
>
> I think it would be a good idea to document each setting, its purpose and
> intentions along with the patch. I'd volunteer to do that.
>
> So is everybody for patching this in Ruby OpenSSL? What if OpenSSL devs
> decide to patch it on their end, should we still patch it ourselves?
>
> -Martin
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Yusuke Endoh <mame@tsg.ne.jp>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>, Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Thu, 16 Jan 2014 12:36:13 +0900
Jeff,
Could you please answer Martin's first question?
> @Jeff: Have you heard anything from the OpenSSL devs, are they willing to
change their defaults?
2014/1/15 Jeff Hodges <jeff@somethingsimilar.com>:
> I am okay with this patch if Ruby is not using the SSLv2 client hello for
mat
> as it seems to be in the configuration. If ruby is using the sslv2
> handshake, it needs to be should be bumped up. SSLv2 was broken back in t
he
> 90s and this makes users susceptible to downgrade attacks.
>
> Yes, the Ruby developers will have to own this configuration change going
> forward. Per earlier discussion, it doesn't matter if OpenSSL changes the
ir
> defaults or not, Ruby will have users with insecure OpenSSL libraries
> installed. There will always be configurations that OpenSSL or any other
> library Ruby needs that will have defaults that will not be safe in Ruby'
s
> security environment and the libraries will have legitimate reasons for
> that.
>
> The Ruby developers already should be monitoring for new SSL/TLS attacks
and
> adjusting to them. Ruby is a popular runtime and its security is the
> security of its users. Ruby can't rely on them to have the latest of
> everything installed. Look at OS X. The default version of OpenSSL is sti
ll
> 0.9.8 and few ever update it. Users don't even *know* to update it.
>
> Punting problems to the users means that more people have to aware and fi
x
> every single possible issue instead of Ruby providing a safe environment
for
> them to work in. And those people simply won't do it, either out of
> laziness, or ignorance. The Ruby developers are a much better position to
> take care of their users.
>
> I note that other runtimes don't have problems owning their security. For
> instance, the CRIME attack was well-known and fixed by Java, Go, all of t
he
> major browsers and many others when it was discovered in 2011. The fact t
hat
> it was not fixed in Ruby (whether or not they had the latest OpenSSL) at
the
> same time is a problem with Ruby. Ruby is the unusual one.
>
> I'm very surprised to be having this debate on this email list.
>
>
>
> On Tue, Jan 14, 2014 at 11:34 PM, Martin Bofllet <martin.bosslet@gmail.c
om>
> wrote:
>>
>>
>>
>>
>> 2014/1/14 Yusuke Endoh <mame@tsg.ne.jp>
>>>
>>> > This patch also explains why folks didn't see ruby having it's own
>>> > defaults
>>> > in the C code.
>>>
>>> Sorry ;-) But I think this issue suggests precisely the disadvantage
>>> of having the own defaults. It is too hard to maintain.
>>>
>>> Anyway, we cannot remove the defaults now for the compatibility. I
>>> agree with the patch. Emboss, what do you think?
>>
>>
>> Personally, I would also prefer if upstream could fix this, if not only
>> for the sake of DRY.
>>
>> @Jeff: Have you heard anything from the OpenSSL devs, are they willing t
o
>> change their defaults?
>>
>> If they are not, I understand the arguments for patching this in Ruby
>> OpenSSL itself. The reason for my concerns is that patching in return me
ans
>> we'll have to monitor OpenSSL (C library) defaults very closely in the
>> future. We must adopt any future changes and we must react if they shoul
d
>> change defaults internally altogether. If we miss one of those changes a
nd a
>> vulnerability evolves from this everybody will point fingers at us for n
ot
>> sticking to the library defaults.
>>
>> @Jeff: With the addition of !SEED:!IDEA, you would agree to the patch?
>>
>> I think it would be a good idea to document each setting, its purpose an
d
>> intentions along with the patch. I'd volunteer to do that.
>>
>> So is everybody for patching this in Ruby OpenSSL? What if OpenSSL devs
>> decide to patch it on their end, should we still patch it ourselves?
>>
>> -Martin
>
>
--
Yusuke Endoh <mame@tsg.ne.jp>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Yusuke Endoh <mame@tsg.ne.jp>
Cc: =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>, Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Wed, 15 Jan 2014 19:45:09 -0800
Yes, one has, but they've not moved beyond that. Again, that doesn't matter.
On Wed, Jan 15, 2014 at 7:36 PM, Yusuke Endoh <mame@tsg.ne.jp> wrote:
> Jeff,
>
> Could you please answer Martin's first question?
>
> > @Jeff: Have you heard anything from the OpenSSL devs, are they willing
> to change their defaults?
>
> 2014/1/15 Jeff Hodges <jeff@somethingsimilar.com>:
> > I am okay with this patch if Ruby is not using the SSLv2 client hello
> format
> > as it seems to be in the configuration. If ruby is using the sslv2
> > handshake, it needs to be should be bumped up. SSLv2 was broken back in
> the
> > 90s and this makes users susceptible to downgrade attacks.
> >
> > Yes, the Ruby developers will have to own this configuration change going
> > forward. Per earlier discussion, it doesn't matter if OpenSSL changes
> their
> > defaults or not, Ruby will have users with insecure OpenSSL libraries
> > installed. There will always be configurations that OpenSSL or any other
> > library Ruby needs that will have defaults that will not be safe in
> Ruby's
> > security environment and the libraries will have legitimate reasons for
> > that.
> >
> > The Ruby developers already should be monitoring for new SSL/TLS attacks
> and
> > adjusting to them. Ruby is a popular runtime and its security is the
> > security of its users. Ruby can't rely on them to have the latest of
> > everything installed. Look at OS X. The default version of OpenSSL is
> still
> > 0.9.8 and few ever update it. Users don't even *know* to update it.
> >
> > Punting problems to the users means that more people have to aware and
> fix
> > every single possible issue instead of Ruby providing a safe environment
> for
> > them to work in. And those people simply won't do it, either out of
> > laziness, or ignorance. The Ruby developers are a much better position to
> > take care of their users.
> >
> > I note that other runtimes don't have problems owning their security. For
> > instance, the CRIME attack was well-known and fixed by Java, Go, all of
> the
> > major browsers and many others when it was discovered in 2011. The fact
> that
> > it was not fixed in Ruby (whether or not they had the latest OpenSSL) at
> the
> > same time is a problem with Ruby. Ruby is the unusual one.
> >
> > I'm very surprised to be having this debate on this email list.
> >
> >
> >
> > On Tue, Jan 14, 2014 at 11:34 PM, Martin Boßlet <
> martin.bosslet@gmail.com>
> > wrote:
> >>
> >>
> >>
> >>
> >> 2014/1/14 Yusuke Endoh <mame@tsg.ne.jp>
> >>>
> >>> > This patch also explains why folks didn't see ruby having it's own
> >>> > defaults
> >>> > in the C code.
> >>>
> >>> Sorry ;-) But I think this issue suggests precisely the disadvantage
> >>> of having the own defaults. It is too hard to maintain.
> >>>
> >>> Anyway, we cannot remove the defaults now for the compatibility. I
> >>> agree with the patch. Emboss, what do you think?
> >>
> >>
> >> Personally, I would also prefer if upstream could fix this, if not only
> >> for the sake of DRY.
> >>
> >> @Jeff: Have you heard anything from the OpenSSL devs, are they willing
> to
> >> change their defaults?
> >>
> >> If they are not, I understand the arguments for patching this in Ruby
> >> OpenSSL itself. The reason for my concerns is that patching in return
> means
> >> we'll have to monitor OpenSSL (C library) defaults very closely in the
> >> future. We must adopt any future changes and we must react if they
> should
> >> change defaults internally altogether. If we miss one of those changes
> and a
> >> vulnerability evolves from this everybody will point fingers at us for
> not
> >> sticking to the library defaults.
> >>
> >> @Jeff: With the addition of !SEED:!IDEA, you would agree to the patch?
> >>
> >> I think it would be a good idea to document each setting, its purpose
> and
> >> intentions along with the patch. I'd volunteer to do that.
> >>
> >> So is everybody for patching this in Ruby OpenSSL? What if OpenSSL devs
> >> decide to patch it on their end, should we still patch it ourselves?
> >>
> >> -Martin
> >
> >
>
>
>
> --
> Yusuke Endoh <mame@tsg.ne.jp>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Yusuke Endoh <mame@tsg.ne.jp>
Cc: =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>, Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Wed, 15 Jan 2014 19:53:08 -0800
http://rt.openssl.org/Ticket/Display.html?id=3231
On Wed, Jan 15, 2014 at 7:45 PM, Jeff Hodges <jeff@somethingsimilar.com>wrote:
> Yes, one has, but they've not moved beyond that. Again, that doesn't
> matter.
>
>
>>
>>
>> --
>> Yusuke Endoh <mame@tsg.ne.jp>
>>
>
>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Yusuke Endoh <mame@tsg.ne.jp>
To: Jeff Hodges <jeff@somethingsimilar.com>
Cc: =?ISO-8859-1?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>, Nobuyoshi Nakada <nobu@ruby-lang.org>, security <security@ruby-lang.org>
Date: Thu, 16 Jan 2014 23:27:24 +0900
> Yes, one has, but they've not moved beyond that. Again, that doesn't matter.
Thank you. I think it actually matters because, IMO, they are our
authority about all decisions related to Ruby OpenSSL.
Ruby is a voluntary project. Ruby is not a project for security.
There are few developers who are familiar with SSL/TLS details.
Martin is a notable exception and thus he is the current maintainer of
Ruby OpenSSL, but note that he is not even the original author. It is
important that he is reluctant to maintain our own security policy.
Even if he were willing to do so, I would be negative since it looks
too hard and rather dangerous for only one person to determine such a
sensitive thing.
In this case, we must delegate the task to other people. I believe it
would be much better than using our dogmatic policy irresponsibly.
The best authority of that decision is definitely the OpenSSL project
itself. In the sense, its action are very important for us.
> Look at OS X. The default version of OpenSSL is still 0.9.8 and few ever update it.
In general, it is a bad idea for Ruby to work around any issue of OS.
OS X is a commercial project. Why don't you negotiate Apple?
> The Ruby developers are a much better position to take care of their users.
I can understand this point, but I don't think we can afford it enough.
That being said, the current Ruby OpenSSL actually has the own
defaults. It is very unfortunate, we cannot remove it right now for
the compatibility reason. So I agreed with nobu's patch as a
temporary measure. But, IMO, the code should be removed in the
future.
Thank you,
--
Yusuke Endoh <mame@tsg.ne.jp>
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Charlie Somerville <charliesome@ruby-lang.org>
To: Yusuke Endoh <mame@tsg.ne.jp>
Cc: Jeff Hodges <jeff@somethingsimilar.com>, security <security@ruby-lang.org>, =?utf-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>
Date: Fri, 17 Jan 2014 01:47:02 +1100
On Friday, 17 January 2014 at 1:27 am, Yusuke Endoh wrote:
> There are few developers who are familiar with SSL/TLS details.
This is true, and this is why IMO it is so important that Ruby provides secure defaults.
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Dirkjan Bussink <d.bussink@gmail.com>
To: Jeff Hodges <jeff@somethingsimilar.com>, security <security@ruby-lang.org>, =?windows-1252?Q?Martin_Bo=DFlet?= <martin.bosslet@gmail.com>
Date: Thu, 16 Jan 2014 15:57:18 +0100
On 16 Jan 2014, at 15:27, Yusuke Endoh <mame@tsg.ne.jp> wrote:
> Thank you. I think it actually matters because, IMO, they are our
> authority about all decisions related to Ruby OpenSSL.
Sadly the track record here of upstream OpenSSL of providing good
defaults isn’t good. The current defaults are not safe and haven’t
been safe for a very long time. I don’t see this changing, so I don’t
think considering them an authority on this.
> Ruby is a voluntary project. Ruby is not a project for security.
> There are few developers who are familiar with SSL/TLS details.
> Martin is a notable exception and thus he is the current maintainer of
> Ruby OpenSSL, but note that he is not even the original author. It is
> important that he is reluctant to maintain our own security policy.
> Even if he were willing to do so, I would be negative since it looks
> too hard and rather dangerous for only one person to determine such a
> sensitive thing.
I’m more than willing to help out where I can here. I’ve done some
stuff on SSL deployment etc. I don’t consider myself an big expert in
this area, but I believe to know at least enough to help out making
decisions on a topic like this. I’ve worked on the deployment of SSL
at GitHub (https://github.com/blog/1734-improving-our-ssl-setup) and
Jeff has been so kind to also point us at improvements there.
Everyone is fallible here but I refuse to believe that as a Ruby
community we can’t do better than this. Jeff comes to us with this
problem and is knowledgable in the subject. Why not as him and others
like him for help on this? Why not have them review these lists?
Right now we are at a point where we definitely know not doing something
is irresponsible to our users, so we should improve it here. It’s more
a matter of taking this responsibility because throwing this back to
OpenSSL is seriously irresponsible imho.
>> The Ruby developers are a much better position to take care of their
users.
>
> I can understand this point, but I don't think we can afford it
enough.
I think here Ruby must. There are a lot of people who depend on Ruby for
all kinds of things these days and I feel this is a responsibility that
can’t be ignored. We can’t just throw up our hands in the air and
ignore this problem and hope it goes away.
—
Regards,
Dirkjan Bussink
Subject: Re: ruby 1.9 & 2.1 susceptible to the CRIME attack and uses weak cipher suites
From: Jeff Hodges <jeff@somethingsimilar.com>
To: Dirkjan Bussink <d.bussink@gmail.com>
Cc: security <security@ruby-lang.org>, =?UTF-8?Q?Martin_Bo=C3=9Flet?= <martin.bosslet@gmail.com>
Date: Thu, 16 Jan 2014 16:09:47 -0800
It's now been 4 days and 30 emails with no patch merged in and continuing
debate about the purpose of the proposed patch.
These issues expose Ruby users to attacks known for many years, and are
trivial to discover. The Ruby core developers on security@ currently do not
believe these issues are in the purview of Ruby nor urgent enough to have
their patches merged in.
I will make a public ticket on <bugs.ruby-lang.org> for this issue to be
tracked and announced. This will allow others to be made aware of the
issues and to correct their code. The time for private disclosure is over.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment