SSL_OP_ALL incorrectly disables TLS 1.1

Bug #1018998 reported by Marc Deslauriers
272
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenSSL
Fix Released
Unknown
openssl (Ubuntu)
Fix Released
Undecided
Unassigned
Precise
Fix Released
Undecided
Marc Deslauriers
Quantal
Fix Released
Undecided
Unassigned

Bug Description

From the openssl 1.0.1b changelog:

  *) OpenSSL 1.0.0 sets SSL_OP_ALL to 0x80000FFFL and OpenSSL 1.0.1 and
     1.0.1a set SSL_OP_NO_TLSv1_1 to 0x00000400L which would unfortunately
     mean any application compiled against OpenSSL 1.0.0 headers setting
     SSL_OP_ALL would also set SSL_OP_NO_TLSv1_1, unintentionally disablng
     TLS 1.1 also. Fix this by changing the value of SSL_OP_NO_TLSv1_1 to
     0x10000000L Any application which was previously compiled against
     OpenSSL 1.0.1 or 1.0.1a headers and which cares about SSL_OP_NO_TLSv1_1
     will need to be recompiled as a result. Letting be results in
     inability to disable specifically TLS 1.1 and in client context,
     in unlike event, limit maximum offered version to TLS 1.0

Any package in the repo that got compiled on oneiric, or on precise before 2012-03-24 02:03:49 EDT got compiled with SSL_OP_ALL set to 0x80000FFFL, and is telling openssl on precise to disable tls v1.1.

openssl 1.0.1 had SSL_OP_ALL set to 0x80000BFFL.

We have two choices:

1- We rebuild all packages that are in the archive that were built before 2012-03-24 02:03:49 EDT so they set SSL_OP_ALL to 0x80000BFFL. Unfortunately, that means when we push 1.0.1b to quantal, they will no longer be able to use SSL_OP_NO_TLSv1_1 to disable tlsv1.1 during runtime.

2- We issue an openssl security update for precise and quantal that switches SSL_OP_NO_TLSv1_1 to 0x10000000L, as in 1.0.1b. This means old applications will not disable tls v1.1 by accident, but will no longer be able to use SSL_OP_NO_TLSv1_1 to disable tlsv1.1 during runtime. If some applications are known to rely on runtime disabling of tls v1.1, we can simply rebuild them once the openssl security update has been pushed out.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

apache2 in the precise release pocket is affected by this, since it was built before precise gained openssl 1.0.1. The apache2 in precise-proposed is not affected.

tags: added: rls-q-incoming
Changed in openssl (Ubuntu Precise):
assignee: nobody → Marc Deslauriers (mdeslaur)
Revision history for this message
Adam Conrad (adconrad) wrote :

13:59 < infinity> mdeslaur: Well, it seems to me that option #2 is the only sane way forward.
13:59 <@mdeslaur> infinity: yes, I agree
13:59 <@mdeslaur> writing it down cleared that up

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openssl (Ubuntu Precise):
status: New → Confirmed
Changed in openssl (Ubuntu):
status: New → Confirmed
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :
Changed in openssl (Ubuntu Quantal):
status: Confirmed → Fix Released
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

How to test:

1- Install apache from the precise release pocket (not from -proposed, or -updates)
2- See if you can connect using tls v1.1: openssl s_client -tls1_1 -connect $HOST:$PORT

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

SRU team:

This is a security update that has been copied to -proposed to get more testing. This needs to be released by the security team.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openssl - 1.0.1-4ubuntu5.3

---------------
openssl (1.0.1-4ubuntu5.3) precise-security; urgency=low

  * SECURITY UPDATE: SSL_OP_ALL incorrectly disables TLS 1.1 (LP: #1018998)
    - debian/patches/lp1018998.patch: change SSL_OP_NO_TLSv1_1 from
      0x00000400L to 0x10000000L as in 1.0.1b to prevent applications
      compiled with SSL_OP_ALL from incorrectly disabling TLS 1.1.
  * debian/patches/lp1020621.patch: Make renegotiation work for TLS 1.2, 1.1
    by not using a lower record version client hello workaround if
    renegotiating. (LP: #1020621)
 -- Marc Deslauriers <email address hidden> Tue, 03 Jul 2012 11:36:01 -0400

Changed in openssl (Ubuntu Precise):
status: Confirmed → Fix Released
Changed in openssl:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.