SSL 3.0 and older ciphers selected in applications
Hi all, 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. If it will help the release team, is there anybody from the security team who could review the changes in my debdiff? Regards, Daniel 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772487 2. https://security-tracker.debian.org/tracker/CVE-2014-3566 -- 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/54855e6d.9000...@pocock.pro
Re: Bug#772487: SSL 3.0 and older ciphers selected in applications
On Mon, 2014-12-08 at 09:16 +0100, Daniel Pocock wrote: [...] If it will help the release team, is there anybody from the security team who could review the changes in my debdiff? Note that debian-security@lists.debian.org is not a contact address for the security team. (Also I don't see anything in the nack mail that says it was related to being unable to review the debdiff.) Regards, Adam -- 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/1418030432.5790.11.ca...@adam-barratt.org.uk
Re: Bug#772487: SSL 3.0 and older ciphers selected in applications
On 08/12/14 10:20, Adam D. Barratt wrote: On Mon, 2014-12-08 at 09:16 +0100, Daniel Pocock wrote: [...] If it will help the release team, is there anybody from the security team who could review the changes in my debdiff? Note that debian-security@lists.debian.org is not a contact address for the security team. (Also I don't see anything in the nack mail that says it was related to being unable to review the debdiff.) I wasn't suggesting that was the cause for the nack email although I remember some discussion around the wheezy release that the size of diffs is considered a factor in unblock requests. I understand that sometimes the security team have made decisions about what should go through to stable, e.g. for the browser version updates and the security team are also getting involved if some vulnerability is found in future so I value their opinion on this particular case. The WebSocket transport (which includes TLS support) in packages like reSIProcate, Kamailio and Asterisk needs to remain interoperable with the browsers and the server side also needs to remain secure throughout the life of jessie so there are a range of reasons I'm asking about this. -- 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/54856fa5.8020...@pocock.pro
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 -- 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
Re: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote: Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() This has no effect in jessie. SSLv2 and SSLv3 are disabled if you use the SSLv23_* methods. The only way to enable SSLv3 is to use the SSLv3_* methods. You should always use the SSLv23 method as those are the only that support more than 1 protocol version. I would love to see people stopping the SSLv3 methods, and they have been removed in experimental. I'm also working on only having the SSLv23 method available. Kurt -- 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/20141208101220.ga13...@roeckx.be
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
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 11:12, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote: Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() This has no effect in jessie. SSLv2 and SSLv3 are disabled if you use the SSLv23_* methods. The only way to enable SSLv3 is to use the SSLv3_* methods. You should always use the SSLv23 method as those are the only that support more than 1 protocol version. Can you please clarify that - if somebody explicitly calls SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support for SSLv3 in SSLv23_method? I would love to see people stopping the SSLv3 methods, and they have been removed in experimental. I'm also working on only having the SSLv23 method available. In VoIP, this is not so trivial. People have devices like IP phones and ISDN gateways to use on their LAN. Some of the older ones may not support anything more than SSL v3 very well. If these devices are used on a private VLAN then the risk of using old crypto is not the same as the risk on the public Internet so I prefer to give these people config options to support their hardware but disabled by default. Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? There is an example of it here: https://issues.asterisk.org/jira/browse/ASTERISK-13845 and it looks something like this: Secure Sockets Layer SSLv2 Record Layer: Client Hello ... Version: TLS 1.0 (0x0301) ... I've noticed that the reSIProcate code using TLSv1_method refuses to accept connections from peers like that. Should SSLv23_method support that even with v2 and v3 disabled? -- 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/54858094.6070...@pocock.pro
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. -- 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/548596b2.1090...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 12:36, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 11:42:28AM +0100, Daniel Pocock wrote: On 08/12/14 11:12, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote: Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() This has no effect in jessie. SSLv2 and SSLv3 are disabled if you use the SSLv23_* methods. The only way to enable SSLv3 is to use the SSLv3_* methods. You should always use the SSLv23 method as those are the only that support more than 1 protocol version. Can you please clarify that - if somebody explicitly calls SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support for SSLv3 in SSLv23_method? No, the library doesn't support SSLv3 in combination with the SSLv23 method. Setting or clearing SSL_OP_NO_SSLv3 doesn't have any effect. Thanks for confirming that. I would love to see people stopping the SSLv3 methods, and they have been removed in experimental. I'm also working on only having the SSLv23 method available. In VoIP, this is not so trivial. People have devices like IP phones and ISDN gateways to use on their LAN. Some of the older ones may not support anything more than SSL v3 very well. If these devices are used on a private VLAN then the risk of using old crypto is not the same as the risk on the public Internet so I prefer to give these people config options to support their hardware but disabled by default. So why use SSL at all? Only for cases where people may already have it configured that way. It is not an issue for my own personal use cases. Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? I would expect that both should support that. With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 There is an example of it here: https://issues.asterisk.org/jira/browse/ASTERISK-13845 and it looks something like this: Secure Sockets Layer SSLv2 Record Layer: Client Hello ... Version: TLS 1.0 (0x0301) ... I've noticed that the reSIProcate code using TLSv1_method refuses to accept connections from peers like that. Should SSLv23_method support that even with v2 and v3 disabled? Yes it should. -- 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/54859797.6070...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote: Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? I would expect that both should support that. With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 So I start an s_server with: openssl s_server -tls1 And then: openssl s_client: TLSv1 openssl s_client -tls1: TLSv1 I tried the s_server and s_client on both jessie and wheezy. This should just work. If both sides drop the -tls1 of course changes to TLSv1.2. But it really should always work, and if doesn't I'd argue that's a bug. But you say that it sends an SSLv2 compatible client hello. By default it shouldn't be doing that unless you change the ciphers suite to include SSLv2 ciphers and aren't using any extentions, and as far as I know you currently can't disable extentions in either wheez or jessie. Kurt -- 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/20141208125312.gc11...@roeckx.be
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 13:53, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote: Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? I would expect that both should support that. With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 So I start an s_server with: openssl s_server -tls1 And then: openssl s_client: TLSv1 openssl s_client -tls1: TLSv1 I tried the s_server and s_client on both jessie and wheezy. This should just work. If both sides drop the -tls1 of course changes to TLSv1.2. But it really should always work, and if doesn't I'd argue that's a bug. But you say that it sends an SSLv2 compatible client hello. By default it shouldn't be doing that unless you change the ciphers suite to include SSLv2 ciphers and aren't using any extentions, and as far as I know you currently can't disable extentions in either wheez or jessie. It is the opposite - the remote system is sending the SSLv2 compatible client hello. The Debian/repro system is the server side. I have no idea what technology is in use in the remote/client system. If my server socket is using TLSv1_method it is rejecting the connection and logging those errors on my server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 My server then sends TCP RST to the client -- 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/5485a904.4090...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 02:35:00PM +0100, Daniel Pocock wrote: I have no idea what technology is in use in the remote/client system. If my server socket is using TLSv1_method it is rejecting the connection and logging those errors on my server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 My server then sends TCP RST to the client So I can actually reproduce this with the s_client from squeeze, since that still generates an SSLv2 compatible client hello. That does fail talking to any server using the TLSv1 method but works talking to the SSLv23 method. Since I'm actually going to remove support for the TLSv1 method I don't intend to fix this. Kurt -- 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/20141208175834.ga11...@roeckx.be
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 18:58, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 02:35:00PM +0100, Daniel Pocock wrote: I have no idea what technology is in use in the remote/client system. If my server socket is using TLSv1_method it is rejecting the connection and logging those errors on my server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 My server then sends TCP RST to the client So I can actually reproduce this with the s_client from squeeze, since that still generates an SSLv2 compatible client hello. That does fail talking to any server using the TLSv1 method but works talking to the SSLv23 method. Since I'm actually going to remove support for the TLSv1 method I don't intend to fix this. Will the TLSv1 method be removed in jessie or while jessie is still supported? If so, then applications like repro that use it by default will need to be patched. -- 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/5485ec69.2030...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 07:22:33PM +0100, Daniel Pocock wrote: Will the TLSv1 method be removed in jessie or while jessie is still supported? This is something post jessie. Kurt -- 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/20141208182501.ga3...@roeckx.be
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 19:25, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 07:22:33PM +0100, Daniel Pocock wrote: Will the TLSv1 method be removed in jessie or while jessie is still supported? This is something post jessie. Is it something that is going to happen with Ubuntu releases next year (e.g. April 2015)? If so, it means that the repro package in jessie won't talk to a repro package in Ubuntu. -- 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/5485f12e.9090...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 07:42:54PM +0100, Daniel Pocock wrote: Is it something that is going to happen with Ubuntu releases next year (e.g. April 2015)? If so, it means that the repro package in jessie won't talk to a repro package in Ubuntu. I think there is some misunderstanding. People have been using methods like SSLv3_* and TLSv1_* while they should use SSLv23_*. SSLv3_* only support SSL 3.0, TLSv1_* only support TLS 1.0, it does not support SSL 3.0 or TLS 1.1. SSLv23_* on the other hand supports all versions supported by library (but see below). The intention is to drop all methods that only support 1 protocol version and instead have only methods that support all versions (SSLv23). The library in jessie supports TLS 1.0 to TLS 1.2. However the the SSLv3 methods still exist in jessie so you can still talk SSL 3.0 in jessie. However the SSLv23 methods do not support SSL 3.0 in jessie anymore. They still supports SSL 3.0 in wheezy. That means if one side uses SSLv3_* and the the verion in jessie or later use SSLv23_* they will not talk to each other. And there are packages that have been fixed to stop using the SSLv3_* methods in jessie and they will not talk to the version in wheezy. The versie in wheezy really should also get fixed to use the SSLv23_* method. The SSLv3_* method has been removed in experimental and the TLSv1_* method will also be removed post jessie but I have no timeframe for that. But everybody really should only use the SSLv23_* methods. But the removal of the TLSv1_* methods should not cause any issue if you replace it by the SSLv23_* methods since there currently are no plans to drop support for TLS 1.0. Kurt -- 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/20141208190631.ga20...@roeckx.be
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 20:06, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 07:42:54PM +0100, Daniel Pocock wrote: Is it something that is going to happen with Ubuntu releases next year (e.g. April 2015)? If so, it means that the repro package in jessie won't talk to a repro package in Ubuntu. I think there is some misunderstanding. People have been using methods like SSLv3_* and TLSv1_* while they should use SSLv23_*. SSLv3_* only support SSL 3.0, TLSv1_* only support TLS 1.0, it does not support SSL 3.0 or TLS 1.1. SSLv23_* on the other hand supports all versions supported by library (but see below). The intention is to drop all methods that only support 1 protocol version and instead have only methods that support all versions (SSLv23). The library in jessie supports TLS 1.0 to TLS 1.2. However the the SSLv3 methods still exist in jessie so you can still talk SSL 3.0 in jessie. However the SSLv23 methods do not support SSL 3.0 in jessie anymore. They still supports SSL 3.0 in wheezy. That means if one side uses SSLv3_* and the the verion in jessie or later use SSLv23_* they will not talk to each other. And there are packages that have been fixed to stop using the SSLv3_* methods in jessie and they will not talk to the version in wheezy. The versie in wheezy really should also get fixed to use the SSLv23_* method. The SSLv3_* method has been removed in experimental and the TLSv1_* method will also be removed post jessie but I have no timeframe for that. But everybody really should only use the SSLv23_* methods. But the removal of the TLSv1_* methods should not cause any issue if you replace it by the SSLv23_* methods since there currently are no plans to drop support for TLS 1.0. What we have right now in jessie (and wheezy) is hard-coded to use TLSv1_method. The v1.9.8-1 upload to unstable, which will also propagate to the next Ubuntu and will also be uploaded to Fedora very soon, uses SSLv23_method If I understand your reply correctly, the version in Ubuntu and Fedora will still talk TLS 1.0 with the version now waiting in jessie? Do you believe it would be reasonable for me to request a smaller unblock that just changes the call TLSv1_method to SSLv23_method? -- 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/5485f961.8080...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote: If I understand your reply correctly, the version in Ubuntu and Fedora will still talk TLS 1.0 with the version now waiting in jessie? Yes. Do you believe it would be reasonable for me to request a smaller unblock that just changes the call TLSv1_method to SSLv23_method? That depends on wether it's acting as client or server. If it's acting as server I say yes. If it's acting as client I suggest you also have a way to turn off TLS 1.2. I understand that it needs to be able to talk to many different things and TLS 1.2 has has been breaking things it shouldn't and you already indicated problems with some products. But maybe it just needs to be used for a while with the SSLv23 method to see if there are problems or not. Kurt -- 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/20141208201618.ga18...@roeckx.be
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 21:16, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote: If I understand your reply correctly, the version in Ubuntu and Fedora will still talk TLS 1.0 with the version now waiting in jessie? Yes. Do you believe it would be reasonable for me to request a smaller unblock that just changes the call TLSv1_method to SSLv23_method? That depends on wether it's acting as client or server. If it's acting as server I say yes. If it's acting as client I suggest you also have a way to turn off TLS 1.2. I understand that it needs to be able to talk to many different things and TLS 1.2 has has been breaking things it shouldn't and you already indicated problems with some products. But maybe it just needs to be used for a while with the SSLv23 method to see if there are problems or not. It plays a few roles: a) repro acts as a WebSocket server (for WebRTC) b) in federated SIP, repro acts as both server and client c) in a phone system, repro acts as server (e.g. my home phone system has some Polycom desk phones, Jitsi with JDK1.7 and Lumicall on Android as clients) d) people use the reSIProcate library in all kinds of products where it is client (e.g. in Counterpath softphones) or server (e.g. in some commercial Session Border Controllers). All of these use cases are supported by the Debian packages. For the SIP proxy, repro, the smallest possible change to use SSLv23 as default would involve touching 6 lines of code in repro/ReproRunner.cxx, replacing SecurityTypes::TLSv1 with SecurityTypes::SSLv23 on each. As well as changing the server behavior, this also has the effect of enabling TLS 1.2 when acting as client in a federated SIP connection. For other uses of the library it is up to the developer to select SSLv23 when they call SipStack::addTransport -- 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/548609e1.7040...@pocock.pro
RE: [SECURITY] [DSA 3094-1] bind9 security update
We don't run the bind9 server on production appliances, but we do pull in the bind9 client libs and tools, so that will need updating. -Original Message- From: Giuseppe Iuculano [mailto:iucul...@debian.org] Sent: Monday, December 08, 2014 4:43 PM To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 3094-1] bind9 security update Importance: High -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian Security Advisory DSA-3094-1 secur...@debian.org http://www.debian.org/security/ Giuseppe Iuculano December 08, 2014 http://www.debian.org/security/faq - - Package: bind9 CVE ID : CVE-2014-8500 It was discovered that BIND, a DNS server, is prone to a denial of service vulnerability. By making use of maliciously-constructed zones or a rogue server, an attacker can exploit an oversight in the code BIND 9 uses to follow delegations in the Domain Name Service, causing BIND to issue unlimited queries in an attempt to follow the delegation. This can lead to resource exhaustion and denial of service (up to and including termination of the named server process.) For the stable distribution (wheezy), this problem has been fixed in version 1:9.8.4.dfsg.P1-6+nmu2+deb7u3. For the upcoming stable distribution (jessie), this problem will be fixed soon. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your bind9 packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUhhtUAAoJEI9hzo2UfbETZNgQAK3cYJpGVfcD03AEU5KEkXbO rUor18BYRz6lCPSeLqIuF0OHR+ForpgV0t1CZ2mtexr3MSgve/LZn1LH5/YnYCLT 2A3UEtNgi7hzChbgQbWTLXTGzn1eOMxq1lS/pS40h0eLWrbKO8DIA+YiLzVm6G4a rBqHuF+7CoBcRLckk3G2pu+XUFH7SrSFURu8537/ihLqOU7s1vf26G79XmDxFp1m DHhqJ4A/qRTVwBcTaa7nXkQ3YZ1dNFjiSdq44i8N2NZgXhqPyfkfIEWmYI4pSVHi rWpW8j8K2EagbovTUcEYG4OW0P+R06oYNT3QP9RaDiGfEqge+L8gb+RJIZFkmh2o RDdpg3M4B8OZ9JVl/5x4Jdf6LUpfBe1UtAawNC8Fh7B/Xajgsr7mF7DsTBNDSOh9 5BhhSuZrSw2ZVU4rvC4g06lA6lq6GfXzwY8S0M9Mo3BeqvIr2L6BzX7ONUpmBx3n OAvbTFtaB2LZMoP2JVaa9wMmb2F5c5PMVRphaP+2AxP3KSLOYOCLoEv2gg/6udmU PC48Pyl2mm5TzSM7URZEP1lqx/lasdjg/XKfq/SkT7ZRXZqdd/aDy1M4R3RBNzWw dMH+vUHS4qdI2wxKrLkcOQjlQtqHh6+8fWSFb58OLEm7gJB9rMjtFvzcs4nvWiyh 12hvYBbyAjb6ovdvfYsP =b2o8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208214244.ga21...@sd6-work.iuculano.it -- 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/6E5DEE2EE1D461478BC8045CC3D9C77B2AF68CB9@LCHQEX03.lancope.local
RE: [SECURITY] [DSA 3094-1] bind9 security update
Please disregard my prior message. It was directed to the incorrect recipients. My apologies for any inconvenience that might have been caused. -Original Message- From: Charles Stewart Sent: Monday, December 08, 2014 5:57 PM To: 'debian-security@lists.debian.org'; debian-security-annou...@lists.debian.org Subject: RE: [SECURITY] [DSA 3094-1] bind9 security update We don't run the bind9 server on production appliances, but we do pull in the bind9 client libs and tools, so that will need updating. -Original Message- From: Giuseppe Iuculano [mailto:iucul...@debian.org] Sent: Monday, December 08, 2014 4:43 PM To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 3094-1] bind9 security update Importance: High -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - - Debian Security Advisory DSA-3094-1 secur...@debian.org http://www.debian.org/security/ Giuseppe Iuculano December 08, 2014 http://www.debian.org/security/faq - - Package: bind9 CVE ID : CVE-2014-8500 It was discovered that BIND, a DNS server, is prone to a denial of service vulnerability. By making use of maliciously-constructed zones or a rogue server, an attacker can exploit an oversight in the code BIND 9 uses to follow delegations in the Domain Name Service, causing BIND to issue unlimited queries in an attempt to follow the delegation. This can lead to resource exhaustion and denial of service (up to and including termination of the named server process.) For the stable distribution (wheezy), this problem has been fixed in version 1:9.8.4.dfsg.P1-6+nmu2+deb7u3. For the upcoming stable distribution (jessie), this problem will be fixed soon. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your bind9 packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUhhtUAAoJEI9hzo2UfbETZNgQAK3cYJpGVfcD03AEU5KEkXbO rUor18BYRz6lCPSeLqIuF0OHR+ForpgV0t1CZ2mtexr3MSgve/LZn1LH5/YnYCLT 2A3UEtNgi7hzChbgQbWTLXTGzn1eOMxq1lS/pS40h0eLWrbKO8DIA+YiLzVm6G4a rBqHuF+7CoBcRLckk3G2pu+XUFH7SrSFURu8537/ihLqOU7s1vf26G79XmDxFp1m DHhqJ4A/qRTVwBcTaa7nXkQ3YZ1dNFjiSdq44i8N2NZgXhqPyfkfIEWmYI4pSVHi rWpW8j8K2EagbovTUcEYG4OW0P+R06oYNT3QP9RaDiGfEqge+L8gb+RJIZFkmh2o RDdpg3M4B8OZ9JVl/5x4Jdf6LUpfBe1UtAawNC8Fh7B/Xajgsr7mF7DsTBNDSOh9 5BhhSuZrSw2ZVU4rvC4g06lA6lq6GfXzwY8S0M9Mo3BeqvIr2L6BzX7ONUpmBx3n OAvbTFtaB2LZMoP2JVaa9wMmb2F5c5PMVRphaP+2AxP3KSLOYOCLoEv2gg/6udmU PC48Pyl2mm5TzSM7URZEP1lqx/lasdjg/XKfq/SkT7ZRXZqdd/aDy1M4R3RBNzWw dMH+vUHS4qdI2wxKrLkcOQjlQtqHh6+8fWSFb58OLEm7gJB9rMjtFvzcs4nvWiyh 12hvYBbyAjb6ovdvfYsP =b2o8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208214244.ga21...@sd6-work.iuculano.it -- 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/6E5DEE2EE1D461478BC8045CC3D9C77B2AF68D8B@LCHQEX03.lancope.local
DSA candidates
binutils -- claws-mail -- commons-httpclient -- coreutils -- cpio -- graphviz -- httpcomponents-client -- icecast2 -- jqueryui -- libphp-snoopy -- libyaml -- libyaml-libyaml-perl -- lighttpd -- mpfr4 -- openssl -- pdns-recursor -- polarssl -- pyyaml -- squid -- unbound -- unrtf -- xdg-utils -- zendframework -- asterisk/stable -- c-icap/stable -- chromium-browser/stable -- clamav/stable -- ganglia/stable -- gnutls26/stable -- haskell-tls/stable -- libapache-poi-java/stable -- libav/stable -- libkdcraw/stable -- libreoffice/stable -- libspring-java/stable -- linux/stable -- mantis/stable -- mediawiki/stable -- requests/stable -- ruby1.8/stable -- smarty3/stable -- teeworlds/stable -- tomcat6/stable -- -- The above is a list of DSA candidates based on the tracker's information. One should evaluate the candidates and either add them to dsa-needed.txt or consider tagging them no-dsa. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5486a755.9jiz55uqe18rdddn%atomo64+st...@gmail.com
