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 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a809a52097458dd3b5df17772991fdcc.squir...@aphrodite.kinkhorst.nl
