hard-coded to use OpenSSL TLSv1_method
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:/
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-
* 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.
tags: | removed: verification-needed |
tags: | added: patch |
Changed in resiprocate (Debian): | |
status: | Unknown → Fix Released |
tags: | added: trusty utopic |
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.