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

[Daniel Pocock]

I've opened another bug report for the issue that exists in 1.9.6 (trusty) and is fixed in upstream 1.9.7:
https://bugs.launchpad.net/ubuntu/+source/resiprocate/+bug/1422786

All the changes in the debdiff are bug fixes.  If you really want me to
I can open an Ubuntu bug report for each of them but that is time I
would rather spend actually doing upstream development work.  The two
bug reports I have already opened are the most serious issues.

Given the nature of this package, users will have the best experience by
using the bugfix releases from upstream.  It is intended that a user on
any Ubuntu version should be able to make and receive SIP calls with
users on any other recent Ubuntu version.  The TLS issues fixed in this
code are currently preventing users of the packge on trusty from
receiving calls reliably.

I've also send a request for this package to be considered for the Micro
Release exception:

https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions

Can you please advise me if that request has been received and how long
it will take to evaluate?  I didn't receive any confirmation at all.

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