Comment 6 for bug 1051892

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