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

[Mathieu Trudel-Lapierre]

Daniel,

Your email to the Technical Board appears to have been received:
https://lists.ubuntu.com/archives/technical-
board/2015-February/002080.html

I'm just following the guidelines for SRU here, which make me think this
isn't exactly suitable for SRU without a proper exception from the TB.
For example, there are some changes that aren't quite bugfixes in my
mind:

resip/stack: additional OpenSSL cleanup fn - reordered functions to match order used in this post: http://openssl.6102.n7.nabble.com/Cleanup-procedure-missing-some-calls-td37441.html
resip/stack: Added accessor for TransactionUser FIFO so to obtain stats
rutil: accept case insensitive log level strings

So, for Trusty, it feels to me like the best would be to wait and see
what the TB thinks. I don't think it would be worthwhile to open a bug
report for each one of them separately.

As for the Utopic changes; there is would be useful to have a specific
bug for avoiding TLSv1.2 -- this is because we can then verify each bug
separately, and track regressions. I agree the likelihood of regression
is low, but it's nonetheless the procedure that we should follow, unless
you'd rather also wait for the TB to statute on a micro-release
exception.

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