[Bug 1051892] Re: [Quantal] Regression in TLS 1.2 workarounds

[Tyler Hicks]

Since the upstream bug hasn't received any attention and it is late in
our release cycle, I decided to just keep it simple and carry over the
simple change that we carry in Precise for ssl23_client_hello().

I still think that we have a strange combination of build options with
-DOPENSSL_NO_TLS1_2_CLIENT and -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50. It
looks to me like it should be one or the other, but I'm not comfortable
making that change at this point in the cycle.

I've added a truncate cipher list test case to test-openssl.py in lp:qa-
regression-testing and also ran through test connections to a few of the
servers that have been reported as problematic in bug 965371, bug
986147, and this bug.

Here are the results with Quantal's openssl 1.0.1c-3ubuntu1:

Testing www.mediafire.com:443              	        FAIL
Testing cs3-api.salesforce.com:443         	        pass
Testing graph.facebook.com:443             	        pass
Testing www.paypal.com:443                 	                pass
Testing info.vsu.ru:443                    	                        FAIL
Testing www.evernote.com:443               	        FAIL
Testing d3vwyrdyja2n00.cloudfront.net:443  	FAIL
Testing d18kq98amm3n6k.cloudfront.net:443  	FAIL
Testing userstream.twitter.com:443         	        FAIL

Here are the results after applying the attached debdiff:

Testing www.mediafire.com:443              	        FAIL
Testing cs3-api.salesforce.com:443         	        pass
Testing graph.facebook.com:443             	        pass
Testing www.paypal.com:443                 	                pass
Testing info.vsu.ru:443                    	                        pass
Testing www.evernote.com:443               	        FAIL
Testing d3vwyrdyja2n00.cloudfront.net:443  	pass
Testing d18kq98amm3n6k.cloudfront.net:443  	pass
Testing userstream.twitter.com:443         	        pass

This matches the results in Precise's openssl 1.0.1-4ubuntu5.5:

Testing www.mediafire.com:443              	        FAIL
Testing cs3-api.salesforce.com:443         	        pass
Testing graph.facebook.com:443             	        pass
Testing www.paypal.com:443                 	                pass
Testing info.vsu.ru:443                    	                        pass
Testing www.evernote.com:443               	        FAIL
Testing d3vwyrdyja2n00.cloudfront.net:443  	pass
Testing d18kq98amm3n6k.cloudfront.net:443  	pass
Testing userstream.twitter.com:443         	        pass

** Patch added: "openssl_1.0.1c-3ubuntu2.debdiff"
   https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1051892/+attachment/3373510/+files/openssl_1.0.1c-3ubuntu2.debdiff

** Changed in: openssl (Ubuntu)
     Assignee: Tyler Hicks (tyhicks) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1051892

Title:
  [Quantal] Regression in TLS 1.2 workarounds

Status in OpenSSL cryptography and SSL/TLS toolkit:
  Unknown
Status in “openssl” package in Ubuntu:
  Triaged

Bug description:
  openssl 1.0.1c-3ubuntu1 dropped almost all of
  debian/patches/tls12_workarounds.patch because the upstream 1.0.1c
  release contained the changes.

  However, the dropped pieces of tls12_workarounds.patch had a subtle
  difference from upstream. In the Ubuntu patch, ssl23_client_hello()
  checked the *client* TLS version when deciding if the cipher list
  should be truncated or not for TLS 1.2. The upstream code
  (http://cvs.openssl.org/chngview?cn=22408) checks the *negotiated* TLS
  version, which I believe is incorrect since the ServerHello hasn't
  even occurred yet in order to negotiate the TLS version.

  The change from TLS1_get_versions() to TLS1_get_client_versions() was
  discussed here:

  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/986147/comments/4

  This bug can be reproduced with the following command:

  $ openssl s_client -connect d2chzxaqi4y7f8.cloudfront.net:443 -CApath
  /etc/ssl/certs/

  It will fail unless -tls1 is specified like so:

  $ openssl s_client -connect d2chzxaqi4y7f8.cloudfront.net:443 -CApath
  /etc/ssl/certs/ -tls1

  Making this change fixes the problem (ssl3_client_hello() will
  probably need the same change):

  --- openssl-1.0.1c.orig/ssl/s23_clnt.c  2012-09-17 01:06:06.584617683 -0700
  +++ openssl-1.0.1c/ssl/s23_clnt.c       2012-09-17 02:09:01.140540223 -0700
  @@ -491,7 +491,7 @@
                           * as hack workaround chop number of supported ciphers
                           * to keep it well below this if we use TLS v1.2
                           */
  -                       if (TLS1_get_version(s) >= TLS1_2_VERSION
  +                       if (TLS1_get_client_version(s) >= TLS1_2_VERSION
                                  && i > OPENSSL_MAX_TLS1_2_CIPHER_LENGTH)
                                  i = OPENSSL_MAX_TLS1_2_CIPHER_LENGTH & ~1;
   #endif

To manage notifications about this bug go to:
https://bugs.launchpad.net/openssl/+bug/1051892/+subscriptions