Re: SSL 3.0 and older ciphers selected in applications
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
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.
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.
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.
Cheers,
Thijs
Reply to: