Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Am Sonntag, 19. Oktober 2014, 21:11:01 schrieb Ángel González: > Tim Rühsen wrote: > > Hi Ángel, > > > > thanks for your testing. > > > > I would like to reproduce it - can you tell me what you did exactly ? > > I used a simple server that printed the TLS Client Hello and closed the > connection. > Browsers automatically retried with lower SSL versions. > wget aborted with an «Unable to establish SSL connection.» message > > > The original paper talks about 'client renegotiation dance'. > > What about renegotiation at protocol level ? Isn't it possible that a TLS > > connection goes down to SSLv3 intransparent to the client/server code ? > > AFAIK no. That is protected by the HMAC. The problem is the version > downgrading > on a network error, which can be inserted by a MiTM (and without > TLS_FALLBACK_SCSV the server won't be able to that the client downgraded its > version thinking the server didn't support a greater one). > > > I am not that deep into the TLS/SSL libraries to answer that question > > myself right now. The paper talks about 'proper protocol version > > negotiation' - that seems to need some clarification. > > That's the server replying with a lower protocol version in the same > connection. > The downgrade was a hack for broken servers not properly supporting SSL. > And > we are paying it now. Thank you ! Tim
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Tim Rühsen wrote: Hi Ángel, thanks for your testing. I would like to reproduce it - can you tell me what you did exactly ? I used a simple server that printed the TLS Client Hello and closed the connection. Browsers automatically retried with lower SSL versions. wget aborted with an «Unable to establish SSL connection.» message The original paper talks about 'client renegotiation dance'. What about renegotiation at protocol level ? Isn't it possible that a TLS connection goes down to SSLv3 intransparent to the client/server code ? AFAIK no. That is protected by the HMAC. The problem is the version downgrading on a network error, which can be inserted by a MiTM (and without TLS_FALLBACK_SCSV the server won't be able to that the client downgraded its version thinking the server didn't support a greater one). I am not that deep into the TLS/SSL libraries to answer that question myself right now. The paper talks about 'proper protocol version negotiation' - that seems to need some clarification. That's the server replying with a lower protocol version in the same connection. The downgrade was a hack for broken servers not properly supporting SSL. And we are paying it now.
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
On Fri, 2014-10-17 at 21:40 +0200, Tim Rühsen wrote: > Looking at the thread 'SSL Poodle attack'. > So far everybody seem to agree to disable SSLv3 in the default settings. > I already posted a patch for OpenSSL and GnuTLS. > > Because 'Poodle' itself does not affect Wget (e.g. you need a Javascript > enabled client for that and Wget does not have a renegotiate mechanism), we > are not in a hurry. SSLv3 *will* cease from the Wget defaults in the next > time, i am sure. Please don't be too concerned. Great... thx : smime.p7s Description: S/MIME cryptographic signature
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Am Freitag, 17. Oktober 2014, 18:02:39 schrieb Christoph Anton Mitterer: > On Thu, 2014-10-16 at 21:34 +0200, Ángel González wrote: > > First of all, note that wget doesn't react to a disconnect with a > > downgraded retry thus > > it is mainly not vulnerable to poodle (you could only use CVE-2014-3566 > > against servers > > not supporting TLS). > > > > Then, even in that case, as an attacker won't be able to dynamically > > connect in the > > background to another site, explotaition would be much harder (something > > like a > > recursive download on an attacker-controlled server (such as http) which > > is redirecting > > _some_ requests to the https target). For little gaining, as it's very > > unlikely that such > > wget would hold any secret for that server connection (I think you would > > need to use > > --load-cookies with a file shared with another -sensitive- batch > > processing). > > Thanks for trying that out... > But often when such issues are found, no long afterwords people can > attack it even more and what seems impossible right now may be possible > then. > > Just look at the whole black magic to defend SSL against all the > CBC/padding, MtE, lucky13 and further attacks... they fixed it and some > time later the attacks where improved and the same issues where back. > > That's why I think SSLv3 should be no longer used, even if wget isn't > that strongly exposed to attacks. > Also one cannot say that people who depend on it wouldn't have had their > time to move on to TLSv1.x... that SSLv3 will/should be phased out, is > clear for years. > So I feel, better proactively disable it (even if not yet necessary) and > affect those who haven't done their homework, instead of waiting too > long and let those suffer who did. Looking at the thread 'SSL Poodle attack'. So far everybody seem to agree to disable SSLv3 in the default settings. I already posted a patch for OpenSSL and GnuTLS. Because 'Poodle' itself does not affect Wget (e.g. you need a Javascript enabled client for that and Wget does not have a renegotiate mechanism), we are not in a hurry. SSLv3 *will* cease from the Wget defaults in the next time, i am sure. Please don't be too concerned. Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
On Thu, 2014-10-16 at 21:34 +0200, Ángel González wrote: > First of all, note that wget doesn't react to a disconnect with a > downgraded retry thus > it is mainly not vulnerable to poodle (you could only use CVE-2014-3566 > against servers > not supporting TLS). > > Then, even in that case, as an attacker won't be able to dynamically > connect in the > background to another site, explotaition would be much harder (something > like a > recursive download on an attacker-controlled server (such as http) which > is redirecting > _some_ requests to the https target). For little gaining, as it's very > unlikely that such > wget would hold any secret for that server connection (I think you would > need to use > --load-cookies with a file shared with another -sensitive- batch > processing). Thanks for trying that out... But often when such issues are found, no long afterwords people can attack it even more and what seems impossible right now may be possible then. Just look at the whole black magic to defend SSL against all the CBC/padding, MtE, lucky13 and further attacks... they fixed it and some time later the attacks where improved and the same issues where back. That's why I think SSLv3 should be no longer used, even if wget isn't that strongly exposed to attacks. Also one cannot say that people who depend on it wouldn't have had their time to move on to TLSv1.x... that SSLv3 will/should be phased out, is clear for years. So I feel, better proactively disable it (even if not yet necessary) and affect those who haven't done their homework, instead of waiting too long and let those suffer who did. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Hey. On Thu, 2014-10-16 at 19:01 +0200, Tim Rühsen wrote: > Thanks for your input. > > We are just discussing that issue (and of course anybody is invited to take > part here on the list). Sorry, I've only saw that one afterwards :) > While we (developers) could change the code in a few minutes, there might be > side effects that we (or others) don't want. At least we need an agreement > with > the maintainers on how the optimal strategy looks like. Well I personally always think about that way: If someone uses e.g. https on a product, he doesn't want data just to be transferred and things-working™, he wants to have it secured. Cause if he just wants things-working™, he could/should have used plain e.g. http. Now it seems that SSLv3 is basically broken now, which means that all people that intentionally used e.g. https, because they wanted security, don't get this anymore - and for them it's typically better that things stop working immediately and they can react, instead of things going on insecurely, just to please those users who actually misused https, because they didn't care for the security and should have used http in the first place. That's why I think it's better to deactivate it without much considerateness for those who shouldn't use TLS/SSL anyway... instead of letting those suffer who intentionally chose it because security is more important for them. > If you are *really* in a hurry, patch the source yourself. > But I guess the distribution maintainers will provide patches in the next few > days. Regarding the maintainers: I've recently had a discussion about such questions on Debian, and while I don't know the attitude of their wget maintainers, it seemed that many people pressed for "distros should at first do nothing and wait for what upstream does". Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Am Donnerstag, 16. Oktober 2014, 22:01:35 schrieb Ángel González: > Ángel González wrote: > > First of all, note that wget doesn't react to a disconnect with a > > downgraded retry thus > > it is mainly not vulnerable to poodle (you could only use > > CVE-2014-3566 against servers > > not supporting TLS). > > Note I tested both openssl and gnutls builds. Then I rebuilt 1.15¹ with > both libraries using > versions prior to poodle announcement. None of them was affected. > > > ¹ I am having some problem with src/Makefile generation, so I didn't > test with master, but that > should be equivalent. Hi Ángel, thanks for your testing. I would like to reproduce it - can you tell me what you did exactly ? The original paper talks about 'client renegotiation dance'. What about renegotiation at protocol level ? Isn't it possible that a TLS connection goes down to SSLv3 intransparent to the client/server code ? I am not that deep into the TLS/SSL libraries to answer that question myself right now. The paper talks about 'proper protocol version negotiation' - that seems to need some clarification. Tim
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Ángel González wrote: First of all, note that wget doesn't react to a disconnect with a downgraded retry thus it is mainly not vulnerable to poodle (you could only use CVE-2014-3566 against servers not supporting TLS). And curl is equally not affected (tested 7.38.0).
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Ángel González wrote: First of all, note that wget doesn't react to a disconnect with a downgraded retry thus it is mainly not vulnerable to poodle (you could only use CVE-2014-3566 against servers not supporting TLS). Note I tested both openssl and gnutls builds. Then I rebuilt 1.15¹ with both libraries using versions prior to poodle announcement. None of them was affected. ¹ I am having some problem with src/Makefile generation, so I didn't test with master, but that should be equivalent.
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
On 16/10/14 19:01, Tim Rühsen wrote: Am Donnerstag, 16. Oktober 2014, 14:03:43 schrieb Christoph Anton Mitterer: Also, it wget seems to have this --secure-protocol=PFS, which seems a bit strange to me, since PFS is not a property of TLS/SSL itself but rather the algorithms used. Especially, when specifying --secure-protocol=PFS one shouldn't end up with SSLv2/3 accidentally :) Thanks for your input. We are just discussing that issue (and of course anybody is invited to take part here on the list). While we (developers) could change the code in a few minutes, there might be side effects that we (or others) don't want. At least we need an agreement with the maintainers on how the optimal strategy looks like. If you are *really* in a hurry, patch the source yourself. But I guess the distribution maintainers will provide patches in the next few days. How we change the default behaviour of Wget and maybe what additional features we want to give to the users still needs a bit of polishing. Regards, Tim First of all, note that wget doesn't react to a disconnect with a downgraded retry thus it is mainly not vulnerable to poodle (you could only use CVE-2014-3566 against servers not supporting TLS). Then, even in that case, as an attacker won't be able to dynamically connect in the background to another site, explotaition would be much harder (something like a recursive download on an attacker-controlled server (such as http) which is redirecting _some_ requests to the https target). For little gaining, as it's very unlikely that such wget would hold any secret for that server connection (I think you would need to use --load-cookies with a file shared with another -sensitive- batch processing). That said, I agree with the proposal of not connecting by default to SSL v3 servers and requiring it to be forced with --secure-protocol or --no-check-certificate.
Re: [Bug-wget] please remove SSLv3 from being used until explicitly specified
Am Donnerstag, 16. Oktober 2014, 14:03:43 schrieb Christoph Anton Mitterer: > Hi. > > Could you please consider to remove SSLv3 (and if not done yet SSLv2 as > well) from being automatically used, while still leaving users the > choice to manually enable it (e.g. via --secure-protocol=SSLv2/3). > > I think it would be a bad idea to expect that these insecure versions > are dropped from the SSL backend libs, since they may be retained for > debugging purposes or people may just use outdated cipher preference > list. > > > Also, it wget seems to have this --secure-protocol=PFS, which seems a > bit strange to me, since PFS is not a property of TLS/SSL itself but > rather the algorithms used. > Especially, when specifying --secure-protocol=PFS one shouldn't end up > with SSLv2/3 accidentally :) Thanks for your input. We are just discussing that issue (and of course anybody is invited to take part here on the list). While we (developers) could change the code in a few minutes, there might be side effects that we (or others) don't want. At least we need an agreement with the maintainers on how the optimal strategy looks like. If you are *really* in a hurry, patch the source yourself. But I guess the distribution maintainers will provide patches in the next few days. How we change the default behaviour of Wget and maybe what additional features we want to give to the users still needs a bit of polishing. Regards, Tim signature.asc Description: This is a digitally signed message part.
[Bug-wget] please remove SSLv3 from being used until explicitly specified
Hi. Could you please consider to remove SSLv3 (and if not done yet SSLv2 as well) from being automatically used, while still leaving users the choice to manually enable it (e.g. via --secure-protocol=SSLv2/3). I think it would be a bad idea to expect that these insecure versions are dropped from the SSL backend libs, since they may be retained for debugging purposes or people may just use outdated cipher preference list. Also, it wget seems to have this --secure-protocol=PFS, which seems a bit strange to me, since PFS is not a property of TLS/SSL itself but rather the algorithms used. Especially, when specifying --secure-protocol=PFS one shouldn't end up with SSLv2/3 accidentally :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
