SSL_OP_ALL incorrectly disables TLS 1.1

Bug #1018998 reported by Marc Deslauriers on 2012-06-28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Fix Released
openssl (Ubuntu)
Marc Deslauriers

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.

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)
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

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
Changed in openssl (Ubuntu Quantal):
status: Confirmed → Fix Released
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

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.

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  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

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