Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 10:48, Thijs Kinkhorst wrote:
> Hi Daniel,
>
> On Mon, December 8, 2014 09:16, Daniel Pocock wrote:
>> I've made some changes to TLS code in reSIProcate
>>
>> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
>>
>> - adding configuration options to override the options to
>> SSL_CTX_set_options (as it is possible there will be some user with old
>> VoIP hardware out there who wants SSL v3)
>>
>> - making the cipher list configurable in repro.config
>>
>> The release team didn't feel these things justify an unblock
>> request[1]. Can anybody comment on this? Looking at the CVE
>> details[2], it appears that some packages still support SSL v3 while
>> I've heard many people just want to turn it off.
>>
>> Is it important for application developers to try and minimize the use
>> of SSL v3 and older ciphers or will these things be phased out by
>> changing the options centrally in the OpenSSL packages?
>>
>> I felt that by putting control of these things in the libresip API and
>> the repro.config file it would help avoid situations where the package
>> needs to be recompiled to deal with security patching and therefore
>> reduce the burden on the security updates process.
> Until now, I've been very much in favour of and have been working to get
> changes into jessie that disable SSLv3 in applications and/or that make
> protocols and ciphers configurable. Recent history has shown a lot of
> SSL-related attacks so applications being configurable is indeed quite
> preferable where possible as it's likely that some other attack will pop
> up in the jessie lifetime.
>
> Disabling SSLv3 has indeed been done on the library level. Nonetheless I
You mean the flag is set by default but the flag can be removed at
runtime with SSL_CTX_clear_options?
Or it is necessary to rebuild the OpenSSL binaries to get back SSLv3?
> think disabling it in applications and servers has been useful aswell
> because it aids in a proper understanding of why it doesn't work, and it
> helps against a case where an admin needs to use an SSLv3-enabled library
> for a specific service - he will then still not expose unrelated services
> on the system.
In VoIP, there is a lot of legacy hardware around. People with old IP
phones or ISDN gateway devices on a private VLAN may have a good reason
to keep using SSL v3 and very little risk from doing so and so I wanted
to make sure they still have that choice without re-compiling anything.
For somebody who just installs the package though and wants to use it
for federated SIP or WebRTC on the Internet, I want it to be both secure
and compatible with browsers by default.
> I took a quick glance at your changes. Personally I think the option that
> removes options from the protocols list is rather counterintuitive and
> I've not seen it used in different places. Especially because the ciphers
> option seems to behave exactly opposite: that lists ciphers that /are/
> allowed. The list of allowed ciphers is also not very impressive in terms
> of strongness, not sure where it's sourced from.
My options work exactly the way that SSL_CTX_set_options and
SSL_CTX_clear_options work in OpenSSL. The OpenSSL documents explain
that it works that way:
https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html
I agree it is not intuitive but as the document explains it well and the
individual flags are also explained in the OpenSSL documentation I
thought I would just stick with their approach.
> Nonetheless, I have no power obviously over the release team, and I
> understand that getting non-acute changes in at this point is too late
> since the published deadline for non-RC changes has passed on St Nicholas'
> eve. I can fully understand that these kinds of changes, especially if
> they touch a lot of code, fall fully within the definition of an
> "important" bug as there's no acute breakage currently, also considering
> that the library disables the protocol. We have to live with the fact that
> there will be an inevitable cutoff point for any release. We did our best
> to get as much as possible in, and now we'll have to deal with whatever
> ended up in that release through the security channels when the situation
> arrives.
That is what is not so clear to me.
In the SIP proxy (repro.deb package) it just uses TLSv1 by default.
There is no exposure to SSLv3. However, the cipher list may not be
strong enough:
!SSLv2:aRSA+AES:aDSS+AES:@STRENGTH:aRSA+3DES:aDSS+3DES:aRSA+RC4+MEDIUM:aDSS+RC4+MEDIUM:aRSA+DES:aDSS+DES:aRSA+RC4:aDSS+RC4
so the bug I made against repro has severity important.
In the library package (libresiprocate-1.9.deb) there is no default
SSL/TLS mode. It uses whatever the project using the library selects.
If some developer wants to enable dynamic selection of TLS version by
using SSLv23_method then they are going to get SSLv3 too. So I put the
security tag on that bug and made it serious. If the possible use of
SSL v3 is not RC though I can change the severity of that bug down to
important though.
What is your impression of the cipher list though? Should the MEDIUM
entries, DES and RC4 stuff be in there or should I be getting rid of
those and would that potentially justify an unblock or security bug?
Should lintian possibly scan packages to see if they define cipher lists
so they can be checked across the whole distribution or is that already
checked in some way?
Reply to: