hard-coded to use OpenSSL TLSv1_method

Bug #1420956 reported by Daniel Pocock
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
resiprocate (Debian)
Fix Released
Unknown
resiprocate (Ubuntu)
Fix Released
Undecided
Unassigned
Trusty
Fix Released
Medium
Unassigned
Utopic
Fix Released
Medium
Unassigned

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.

Mathew Hodson (mhodson)
tags: removed: verification-needed
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

You can't just sync a new pkg revision to released ubuntu versions. Provide a debdiff to current trusty/utopic pkgs instead and they get sponsored.

Revision history for this message
Daniel Pocock (daniel-pocock) wrote :

Here is the debdiff that was approved for jessie, it will be the same for Ubuntu as there are no patches to the Ubuntu package:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772634

Notice the version number was changed again because of a rejected upload, I eventually had to upload it to NEW as 1:1.9.7-4 but the debdiff is otherwise the same.

Please let me know if this is OK for Utopic

I'll go and prepare a debdiff for Trusty as well

Revision history for this message
Daniel Pocock (daniel-pocock) wrote :
Revision history for this message
Daniel Pocock (daniel-pocock) wrote :
Revision history for this message
Daniel Pocock (daniel-pocock) wrote :

For trusty, the debdiff is a bit bigger because it includes all upstream fixes between 1.9.6 and 1.9.7.

They are itemized one by one in the upstream Git branch for 1.9.x:

https://github.com/resiprocate/resiprocate/commits/resiprocate-1.9

The most critical of these fixes is:

https://github.com/resiprocate/resiprocate/commit/645c9f461ca6e2d9d5167cc9c0ca4781c3e7c19b

Without the fix, some connections are incorrectly closed if there are outstanding issues in the OpenSSL error queue.

This is therefore a compelling fix for any trusty user.

tags: added: patch
Changed in resiprocate (Debian):
status: Unknown → Fix Released
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

The problem with these debdiffs is that we don't ship new versions of packages as stable updates, they would have to land as backports. Stable updates would require just applying https://github.com/resiprocate/resiprocate/commit/645c9f461ca6e2d9d5167cc9c0ca4781c3e7c19b.

Is there any way to apply just that one commit for Trusty?

Also, for Utopic, why is there also 0002-client-avoid-TLSv1_2.patch? I may be a little nitpicky here, but it sounds slightly different than removing the hard-coded use of TLSv1 if we're also purposefully avoiding TLSv1.2 servers. I agree it makes sense, but it feels like it probably should be fixing a separate bug, since the symptoms would be different. What do you think? This seems to me as one case where the change is "on the line", especially if one doesn't understand OpenSSL and TLS well enough.

I'll go ahead and mark the general (vivid) task as Fix Released since resiprocate has been synced from unstable, so we already have 1:1.9.7-4 there.

Thanks!

Changed in resiprocate (Ubuntu):
status: New → Fix Released
Changed in resiprocate (Ubuntu Trusty):
importance: Undecided → Medium
Changed in resiprocate (Ubuntu Utopic):
importance: Undecided → Medium
Changed in resiprocate (Ubuntu Trusty):
status: New → Incomplete
Revision history for this message
Daniel Pocock (daniel-pocock) wrote :

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.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

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.

Revision history for this message
Daniel Pocock (daniel-pocock) wrote :

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.

tags: added: trusty utopic
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

The resiprocate MRE has been approved by the tech board.

I assume the intention behind the debdiffs in comments #3 and #4 is to push the vivid package into trusty and utopic.

I have uploaded packages for trusty and utopic based on the vivid package, but with appropriate versioning for processing by the SRU team.

Thanks!

Changed in resiprocate (Ubuntu Trusty):
status: Incomplete → In Progress
Changed in resiprocate (Ubuntu Utopic):
status: New → In Progress
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Daniel, or anyone else affected,

Accepted resiprocate into utopic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resiprocate/1:1.9.7-4~ubuntu14.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in resiprocate (Ubuntu Utopic):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Daniel, or anyone else affected,

Accepted resiprocate into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resiprocate/1:1.9.7-4~ubuntu14.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in resiprocate (Ubuntu Trusty):
status: In Progress → Fix Committed
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote : [resiprocate/utopic] verification still needed

The fix for this bug has been awaiting testing feedback in the -proposed repository for utopic for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now, the package will be removed from the -proposed repository.

tags: added: removal-candidate
Revision history for this message
Daniel Pocock (daniel-pocock) wrote :

Tested on trusty and utopic

tags: added: verification-done
removed: removal-candidate verification-needed
Revision history for this message
Daniel Pocock (daniel-pocock) wrote :

Tested for both utopic and trusty

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

This bug was fixed in the package resiprocate - 1:1.9.7-4~ubuntu14.04.1

---------------
resiprocate (1:1.9.7-4~ubuntu14.04.1) trusty; urgency=medium

  * Rebuild for Ubuntu 14.04 LTS. (LP: #1420956)
 -- Marc Deslauriers <email address hidden> Tue, 31 Mar 2015 09:21:16 -0400

Changed in resiprocate (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Scott Kitterman (kitterman) wrote : Update Released

The verification of the Stable Release Update for resiprocate has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

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

This bug was fixed in the package resiprocate - 1:1.9.7-4~ubuntu14.10.1

---------------
resiprocate (1:1.9.7-4~ubuntu14.10.1) utopic; urgency=medium

  * Rebuild for Ubuntu 14.10. (LP: #1420956)
 -- Marc Deslauriers <email address hidden> Tue, 31 Mar 2015 09:18:52 -0400

Changed in resiprocate (Ubuntu Utopic):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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