Re: [Bug-wget] SSL Poodle attack
Am Mittwoch, 15. Oktober 2014, 17:26:49 schrieb Daniel Kahn Gillmor: > On 10/15/2014 03:10 PM, Tim Rühsen wrote: > > I tried to make clear that Wget *explicitely* asks for SSLv2 and SSLv3 in > > the default configuration when compiled with OpenSSL. Whatever the > > OpenSSL library vendor is doing... it won't affect Wget in this case. So > > with your attitude, you won't ever be safe ever from Poodle (I guess). > > > > And again my question: should we change the default behaviour of future > > versions of Wget ? > > With other words: since we know, the library vendor wouldn't help in the > > above case, what can we do to secure Wget ? > > hm, i think Tim is on to something here: by default, wget should use the > default ciphersuites and protocol versions selected by the TLS library. > Tweaking the default choices in wget itself tends to make wget more > brittle than the underlying library. > > The only way that should work to try to improve security in wget via TLS > implementation preference strings is if the preference string is > explicitly a minor modification of some system default. This may or may > not be possible depending on the preference string syntax of the > selected TLS implementation. > > (e.g. [for OpenSSL] if the system default is always explicitly > referenced as DEFAULT and we decide that we never want wget to use RC4, > then DEFAULT:-RC4 is a sensible approach, because it allows OpenSSL to > update DEFAULT and wget gains those improvements automatically) Here is a suggestion for a GnuTLS patch. I have a look at OpenSSL ciphers and make a similar patch soon. I also suggested (~1-2 years ago) an option to directly set priority strings / ciphers for GnuTLS and OpenSSL. In situations like these, such an option would allow for a quick reaction done by distribution maintainers and users. What do you think ? Tim From 582a887e61cea2dd0f64d462d919f8688fb7862f Mon Sep 17 00:00:00 2001 From: Tim Ruehsen Date: Thu, 16 Oct 2014 20:44:56 +0200 Subject: [PATCH] GnuTLS: do not use SSLv3 except explicitely requested --- src/ChangeLog | 4 src/gnutls.c | 5 +++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/src/ChangeLog b/src/ChangeLog index 1c4e2d5..00d3c10 100644 --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,7 @@ +2014-10-16 Tim Ruehsen + + * gnutls.c (ssl_connect_wget): do not use SSLv3 except explicitely requested + 2014-05-03 Tim Ruehsen * retr.c (retrieve_url): fixed memory leak diff --git a/src/gnutls.c b/src/gnutls.c index c09b7a2..75627e1 100644 --- a/src/gnutls.c +++ b/src/gnutls.c @@ -436,6 +436,7 @@ ssl_connect_wget (int fd, const char *hostname) switch (opt.secure_protocol) { case secure_protocol_auto: + err = gnutls_priority_set_direct (session, "NORMAL:%COMPAT:-VERS-SSL3.0", NULL); break; case secure_protocol_sslv2: case secure_protocol_sslv3: @@ -445,10 +446,10 @@ ssl_connect_wget (int fd, const char *hostname) err = gnutls_priority_set_direct (session, "NORMAL:-VERS-SSL3.0", NULL); break; case secure_protocol_pfs: - err = gnutls_priority_set_direct (session, "PFS", NULL); + err = gnutls_priority_set_direct (session, "PFS:-VERS-SSL3.0", NULL); if (err != GNUTLS_E_SUCCESS) /* fallback if PFS is not available */ -err = gnutls_priority_set_direct (session, "NORMAL:-RSA", NULL); +err = gnutls_priority_set_direct (session, "NORMAL:-RSA:-VERS-SSL3.0", NULL); break; default: abort (); -- 2.1.1 signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] SSL Poodle attack
On Wed, 15 Oct 2014, Daniel Kahn Gillmor wrote: I agree that OpenSSL has traditionally been too conservative. I'm arguing that if we're going to set anything other than the default, we should make our changes as *relative* changes rather than specifying something absolute, so that wget can get any improvements that OpenSSL makes to the default without having to rebuild wget itself. Ah right, sorry for that detour. This sounds like a sensible approach indeed. -- / daniel.haxx.se
Re: [Bug-wget] SSL Poodle attack
On 10/15/2014 05:37 PM, Daniel Stenberg wrote: > On Wed, 15 Oct 2014, Daniel Kahn Gillmor wrote: > >> (e.g. [for OpenSSL] if the system default is always explicitly >> referenced as DEFAULT and we decide that we never want wget to use >> RC4, then DEFAULT:-RC4 is a sensible approach, because it allows >> OpenSSL to update DEFAULT and wget gains those improvements >> automatically) > > I disagree. OpenSSL is but a TLS library that provides functionality - > and it does so rather conservatively in my view. It does not necessarily > set the security standard for what applications should aim for in a good > manner. > > SSL_DEFAULT_CIPHER_LIST for OpenSSL in my debian unstable (== fairly > recent version 1.0.1i) says "ALL:!aNULL:!eNULL:!SSLv2". > > That means it allows EXPORT40, EXPORT56 and LOW for example (if I'm not > missing something), in addition to RC4. Those are terribly weak ciphers. > > OpenSSL ciphers list is at https://www.openssl.org/docs/apps/ciphers.html I agree that OpenSSL has traditionally been too conservative. I'm arguing that if we're going to set anything other than the default, we should make our changes as *relative* changes rather than specifying something absolute, so that wget can get any improvements that OpenSSL makes to the default without having to rebuild wget itself. --dkg signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] SSL Poodle attack
On Wed, 15 Oct 2014, Daniel Kahn Gillmor wrote: (e.g. [for OpenSSL] if the system default is always explicitly referenced as DEFAULT and we decide that we never want wget to use RC4, then DEFAULT:-RC4 is a sensible approach, because it allows OpenSSL to update DEFAULT and wget gains those improvements automatically) I disagree. OpenSSL is but a TLS library that provides functionality - and it does so rather conservatively in my view. It does not necessarily set the security standard for what applications should aim for in a good manner. SSL_DEFAULT_CIPHER_LIST for OpenSSL in my debian unstable (== fairly recent version 1.0.1i) says "ALL:!aNULL:!eNULL:!SSLv2". That means it allows EXPORT40, EXPORT56 and LOW for example (if I'm not missing something), in addition to RC4. Those are terribly weak ciphers. OpenSSL ciphers list is at https://www.openssl.org/docs/apps/ciphers.html -- / daniel.haxx.se
Re: [Bug-wget] SSL Poodle attack
On 10/15/2014 03:10 PM, Tim Rühsen wrote: > I tried to make clear that Wget *explicitely* asks for SSLv2 and SSLv3 in the > default configuration when compiled with OpenSSL. Whatever the OpenSSL > library > vendor is doing... it won't affect Wget in this case. So with your attitude, > you won't ever be safe ever from Poodle (I guess). > > And again my question: should we change the default behaviour of future > versions of Wget ? > With other words: since we know, the library vendor wouldn't help in the > above > case, what can we do to secure Wget ? hm, i think Tim is on to something here: by default, wget should use the default ciphersuites and protocol versions selected by the TLS library. Tweaking the default choices in wget itself tends to make wget more brittle than the underlying library. The only way that should work to try to improve security in wget via TLS implementation preference strings is if the preference string is explicitly a minor modification of some system default. This may or may not be possible depending on the preference string syntax of the selected TLS implementation. (e.g. [for OpenSSL] if the system default is always explicitly referenced as DEFAULT and we decide that we never want wget to use RC4, then DEFAULT:-RC4 is a sensible approach, because it allows OpenSSL to update DEFAULT and wget gains those improvements automatically) --dkg signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] SSL Poodle attack
Am Mittwoch, 15. Oktober 2014, 13:45:18 schrieb Petr Pisar: > On Wed, Oct 15, 2014 at 11:57:47AM +0200, Tim Rühsen wrote: > > (means, the libraries defaults are used, whatever that is). > > > > Should we break compatibility and map 'auto' to TLSv1 ? > > For the security of the users. > > Please no. Instead of changing each TLS program, one should patch only the > TLS library. This is the reason why why have shared libraries. > > So just report the issue to your vendor, he will fix few TSL implementations > he delivers and all application will get fixed automatically. Hi Petr, I tried to make clear that Wget *explicitely* asks for SSLv2 and SSLv3 in the default configuration when compiled with OpenSSL. Whatever the OpenSSL library vendor is doing... it won't affect Wget in this case. So with your attitude, you won't ever be safe ever from Poodle (I guess). And again my question: should we change the default behaviour of future versions of Wget ? With other words: since we know, the library vendor wouldn't help in the above case, what can we do to secure Wget ? Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] SSL Poodle attack
On Wed, Oct 15, 2014 at 11:57:47AM +0200, Tim Rühsen wrote: > (means, the libraries defaults are used, whatever that is). > > Should we break compatibility and map 'auto' to TLSv1 ? > For the security of the users. Please no. Instead of changing each TLS program, one should patch only the TLS library. This is the reason why why have shared libraries. So just report the issue to your vendor, he will fix few TSL implementations he delivers and all application will get fixed automatically. -- Petr pgpt4V8rcL4IP.pgp Description: PGP signature
[Bug-wget] SSL Poodle attack
Hi, Google people found a new attack that affects SSLv3. see https://www.openssl.org/~bodo/ssl-poodle.pdf http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566 Shortly: there is a design flaw in SSLv3 that implies high security risks. AFAICS, Wget's default SSL protocol is 'auto' which uses (OpenSSL code) case secure_protocol_auto: meth = SSLv23_client_method (); break; or (GnuTLS code) case secure_protocol_auto: break; (means, the libraries defaults are used, whatever that is). Should we break compatibility and map 'auto' to TLSv1 ? For the security of the users. There are only a very few HTTP servers out there, which do not support TLSv1. Or should we let the users/maintainers care for appropriate wgetrc settings ? What do you think ? Tim signature.asc Description: This is a digitally signed message part.