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
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
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
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.
[Bug-wget] Transparent proxy URL ariation on -E -k options ?
Hi, I'm working on a Web-in-a-sandbox project, trying to host shallow (-l 2) copies of several web sites on a server running in a private Internet replica. So far, httrack's -K5 option (which they call transparent proxy URL) appears to do what I need (see http://www.httrack.com/html/httrack.man.html): 1. rename script output of site.com/article.cgi?25 to ./site.com/articleDEADBEEF.css (note the difference from --adjust-extension) 2. rewrite the link in the referencing document as http://site.com/articleDEADBEEF.css?25; which works perfectly when hosting both referencing and referenced sites in the sandbox. I unfortunately found httrack to be otherwise very fragile, and (the major dealbreaker for me) still unable to follow meta refresh links, so I'd like to see wget gain the ability to rename source links and target documents the way httrack's -K5 flag works, as described above. With wget, I'm using -k -E (--convert-links and --adjust-extension) when mirroring these web sites, but would be interested in an alternative way of accomplishing --convert-links. As far as I was able to tell, --adjust-extension will append a .html or .css when saving script output, e.g. from something like http://site.com/article.cgi?25 to ./site.com/article.cgi?25.css but not also rewrite the referencing URL in the document which caused us to recurse and wget the output of this script. If I try to add --convert-links into the mix, the referencing link does get rewritten, but ends up looking like ../site.com/article.cgi?25.html which is designed for offline viewing via file://, and is unsuitable for actually hosting both the referencing and referenced sites as virtual servers in a web server within the sandbox. Am I missing something about wget's capatiblities that would allow me to get it to work in a way similar to httrack's -K5 option ? If not, assuming I can come up with a patch, would there be any interest in upstreaming this type of additional functionality ? Thanks much, --Gabriel
