From: "nahi (Hiroshi Nakamura)" <nakahiro@...>
Date: 2012-11-29T23:14:38+09:00
Subject: [ruby-core:50330] [ruby-trunk - Bug #5353] TLS v1.0 and less - Attack on CBC mode


Issue #5353 has been updated by nahi (Hiroshi Nakamura).

Assignee changed from nahi (Hiroshi Nakamura) to MartinBosslet (Martin Bosslet)

=begin
This could be an option:

 Index: test/openssl/test_ssl.rb
 ===================================================================
 --- test/openssl/test_ssl.rb	(revision 37996)
 +++ test/openssl/test_ssl.rb	(working copy)
 @@ -257,7 +257,7 @@
        ctx = OpenSSL::SSL::SSLContext.new
        ctx.set_params
        assert_equal(OpenSSL::SSL::VERIFY_PEER, ctx.verify_mode)
 -      assert_equal(OpenSSL::SSL::OP_ALL, ctx.options)
 +      assert_equal(OpenSSL::SSL::OP_ALL & ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS, ctx.options)
        ciphers = ctx.ciphers
        ciphers_versions = ciphers.collect{|_, v, _, _| v }
        ciphers_names = ciphers.collect{|v, _, _, _| v }
 @@ -397,6 +397,7 @@
    end
  
    def test_unset_OP_ALL
 +    # Can we safely assume every env has OP_DONT_INSERT_EMPTY_FRAGMENTS?
      ctx_proc = Proc.new { |ctx|
        ctx.options = OpenSSL::SSL::OP_ALL & ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS
      }
 Index: ext/openssl/lib/openssl/ssl.rb
 ===================================================================
 --- ext/openssl/lib/openssl/ssl.rb	(revision 37996)
 +++ ext/openssl/lib/openssl/ssl.rb	(working copy)
 @@ -24,7 +24,9 @@
          :ssl_version => "SSLv23",
          :verify_mode => OpenSSL::SSL::VERIFY_PEER,
          :ciphers => "ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW",
 -        :options => OpenSSL::SSL::OP_ALL,
 +        :options => defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS) ?
 +          OpenSSL::SSL::OP_ALL & ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS :
 +          OpenSSL::SSL::OP_ALL,
        }
  
        DEFAULT_CERT_STORE = OpenSSL::X509::Store.new

...but it causes connection problem for clients, that normally not affected by BEAST.  I'll update WEBrick to disable the bit.

Martin, please close this issue if you're OK. WEBrick thing is a different problem.
=end

----------------------------------------
Bug #5353: TLS v1.0 and less - Attack on CBC mode
https://bugs.ruby-lang.org/issues/5353#change-34151

Author: MartinBosslet (Martin Bosslet)
Status: Assigned
Priority: High
Assignee: MartinBosslet (Martin Bosslet)
Category: ext
Target version: 2.0.0
ruby -v: -


A well-known vulnerability of TLS v1.0 and earlier has recently gained some attention:

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

Although this has been known for a long time (http://www.openssl.org/~bodo/tls-cbc.txt),
and a fix for this has been provided, in reality most applications seem to be working with

SSL_OP_ALL

which is a flag that enables some bug workarounds that were considered harmless. 

We, too, use this in ossl_sslctx_s_alloc(VALUE klass) in ossl_ssl.c. Unfortunately, 
this flag also includes

SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS

which disables the fix for the "CBC vulnerability". Here is what a comment says 
about the flag (OpenSSL 1.0.0d)

    /* Disable SSL 3.0/TLS 1.0 CBC vulnerability workaround that was added
     * in OpenSSL 0.9.6d.  Usually (depending on the application protocol)
     * the workaround is not needed.  Unfortunately some broken SSL/TLS
     * implementations cannot handle it at all, which is why we include
     * it in SSL_OP_ALL. */

If I understand http://www.openssl.org/~bodo/tls-cbc.txt correctly, the most
notable implementation that does not play well with these empty fragments
was (is?) IE - I don't know how this has evolved over time, I would have to 
research further.

An easy fix for the situation would be to discard SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS,
but this would risk affecting existing installations.

What do you propose? Should we solve this before the 1.9.3 release? 

(PS: The actual attack and fix are outlined in 

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf

The attack to be presented by Thai Duong and Juliano Rizzo at 

http://ekoparty.org/cronograma.php (caution: currently the site is victim to the "reddit effect")

is very likely to be based on what was already known and should therefore hopefully
require no further fixes.) 

 


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