[Bug 1420956] Re: hard-coded to use OpenSSL TLSv1_method

[Daniel Pocock]

I agree with your comments about the logger config parsing (rutil:
accept case insensitive log level strings), it is not a bug fix and
therefore it is clearly not in the scope of the SRU policy.

On the other hand, everything on that branch has been carefully cherry-
picked with a view to maintaining stability and avoiding any ABI
breakage.

The other OpenSSL cleanup change was also fixing a bug so if necessary
for SRU then I can open another Ubuntu bug report for that.

The other changes have been in production use for quite a long time now
so they are considered stable.  The upstream "Micro Releases" are
slightly more tolerant than the SRU policy.  This is because the people
working on the code are very familiar with the way it is used, we
usually develop changes on the master branch with the intention that
they should be safe to cherry-pick without ABI breakage.  The logging
configuration improvement is an example of that.  There is another
logging change that couldn't avoid breaking the ABI and so I
deliberately didn't cherry-pick it, I made that other change in a
separate commit and it won't be available until 1.10.x is released.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1420956

Title:
  hard-coded to use OpenSSL TLSv1_method

Status in resiprocate package in Ubuntu:
  Fix Released
Status in resiprocate source package in Trusty:
  Incomplete
Status in resiprocate source package in Utopic:
  New
Status in resiprocate package in Debian:
  Fix Released

Bug description:
  
  Previous upstream releases were hardcoded to use the OpenSSL library's TLSv1_method()

  This was fixed in upstream master branch and backported to the
  upstream 1.9.8 release which now uses SSLv23_method().

  It is discussed here:
  https://lists.debian.org/debian-security/2014/12/msg00032.html

  The patch was also cherry-picked into 1:1.9.7-4 to be allowed into
  Debian testing under a freeze exception

  [Impact]
  * if the user tries to connect to the SIP proxy using a client that doesn't use TLSv1_method, handshake fails
  * if some third party (e.g. an ITSP) is trying to make a connection to the SIP proxy without using TLSv1_method, handshake fails.  This has been observed with connections from a well-known ITSP that starts a TLSv1 handshake with a backwards-compatible SSL v2 client hello.
  * if TLSv1 becomes deprecated, and OpenSSL defaults to a newer version such as v1.1, any application hardcoded to TLSv1_method will be unable to benefit from the new defaults in the library.  Better to proactively get this fixed in case the security team does need to release such changes to OpenSSL during the lifetime of Utopic or Trusty.

  [Test Case]
  * run the SIP proxy
  * use a client that sends an older style client hello, e.g. openssl s_client on a system running Debian squeeze or lenny or a TLS connection from an older JDK version.
  * it is also possible to reproduce with a newer client, e.g. using openssl s_client with the -tls1_2 option

  [Regression Potential]
  * the entire upstream 1.9.x series has been managed by myself with a policy of maintaining ABI compatibility
  * this has been in jessie for a while now too
  * this impacts core functionality of the SIP proxy: its main purpose in life is to handle network connections and TLS handshakes occur at the beginning of most connections.  If there was a regression and connections were to fail, it would be very serious.  Nonetheless, the current situation leads to some connections failing, so this is an acceptable risk to resolve that issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resiprocate/+bug/1420956/+subscriptions