Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 12:04, Thijs Kinkhorst wrote:
> On Mon, December 8, 2014 11:17, Daniel Pocock wrote:
>> 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.
> In non-browser situations I see the possible use as SSLv3 currently as
> undesirable but not as a critical issue. So changes addressing that now
> have missed the freeze deadline. Pity, but nothing can be done about that.
>
>> 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?
> Although we're striving to remove said protocols in jessie, I do not think
> there's currently an acute security issue if they are enabled. And as you
> said yourself, there's a compatibility question at stake in your ecosystem
> which I know nothing about.
There are two possibilities:
a) users of the same product (another repro SIP proxy on Linux), users
of a WebRTC browser (only works on browsers less than 12 months old),
users of Lumicall (Android JVM) or Jitsi (should be JDK 1.6 or greater)
- all basically using recent TLS client code.
b) users of older VoIP hardware
My intention for this package is that users in group (a) should be as
secure as possible, without loss of compatibility, just using the
default cipher list and protocol version in the package.
Users in group (b) should be able to get it working by changing the
configuration but it does not need to work for them with the defaults.
> All in all I see no issues here that would warrant a DSA if they should be
> present. So that makes it clear to me that a freeze exception on these
> grounds is currently also not in reach.
>
>> 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?
> Would be nice, but I'm not sure I can devise a check that would recognise
> cipher lists in a reliable way.
It is probably not hard to scan binaries to see if they call
SSL_CTX_set_cipher_list
Actually detecting the text being passed to that function would be more
tricky though.
Reply to: