bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [PATCH] Allow to redefine ciphers list for OpenSSL


From: Tim Ruehsen
Subject: Re: [Bug-wget] [PATCH] Allow to redefine ciphers list for OpenSSL
Date: Thu, 10 Jul 2014 15:49:07 +0200
User-agent: KMail/4.12.4 (Linux/3.14-1-amd64; KDE/4.13.1; x86_64; ; )

On Thursday 10 July 2014 08:37:23 Tomas Hozza wrote:
> ----- Original Message -----
> 
> > On Tuesday 08 July 2014 16:14:42 Petr Pisar wrote:
> > > On Tue, Jul 08, 2014 at 10:00:24AM -0400, Tomas Hozza wrote:
> > > > I'm afraid this is not suitable for us. We need to be able to define
> > > > the
> > > > policy somewhere in /etc, where the user is not able to change it
> > > > (only
> > > > the system administrator).
> > > 
> > > I hope can also prevent the user from running his own wget executable,
> > > or
> > > ld-preloading modified OpenSSL library, or intercepting open(2) calls to
> > > provide fake /etc file.
> > > 
> > > > Also the main intention to have a single place to set the policy for
> > > > all
> > > > system components, therefore wgetrc is not the right place for us.
> > > 
> > > What about to change wget to call OPENSSL_config(NULL) instead of
> > > setting
> > > some hard-coded preference string. Then you can teach OpenSSL to load
> > > your
> > > /etc configuration instead of patching each application.
> > > 
> > > -- Petr
> > 
> > Tomas intention is to only change the (Wget hard-coded) cipher list for
> > --secure-protocol=PFS. At least, that's what I understood so far.
> 
> It may seem so, but my intention was to be able to redefine any occurrence
> of explicitly hard-coded ciphers priority list. In openssl.c it was only in
> the code that was executed if --secure-protocol=PFS was used.

In this case, you should use a name like --with-PFS-ciphers-list=LIST, because 
you are just changing the PFS hard-coded cipher list. Imagine, we add new --
secure-protocol options with hard-coded values like
--secure-protocol=FOO
--secure-protocol=BAR

In this case you have to create another patch with
./configure --with-ciphers-list-FOO
and
./configure --with-ciphers-list-BAR
since the meanings could be very different. This is why I think it makes sense 
to add 'PFS' to your ./configure option name.

GnuTLS even makes it more complicated since protocols, ciphers, key exchange 
mode etc is read from (currently hard-coded) strings.
Here is the code:
    case secure_protocol_auto:
      break;
    case secure_protocol_sslv2:
    case secure_protocol_sslv3:
      err = gnutls_priority_set_direct (session, "NORMAL:-VERS-TLS-ALL:+VERS-
SSL3.0", NULL);
      break;
    case secure_protocol_tlsv1:
      err = gnutls_priority_set_direct (session, "NORMAL:-VERS-SSL3.0", NULL);
      break;
    case secure_protocol_pfs:
      err = gnutls_priority_set_direct (session, "PFS", NULL);
      if (err != GNUTLS_E_SUCCESS)
        /* fallback if PFS is not available */
        err = gnutls_priority_set_direct (session, "NORMAL:-RSA", NULL);
      break;

You have to provide configure options for each of these (--secure-
protocol=sslv2|sslv3|tlsv1|pfs) e.g.

--with-ciphers-list-sslv2
--with-ciphers-list-sslv3
--with-ciphers-list-tlsv1
--with-ciphers-list-pfs

And I am sure there will be more options in the future and I guess the Wget 
people will have to maintain the above configure options in the future for you 
/ Redhat. And that would be clear going with my above suggestions.

Also very likely is a command line option to freely specify OpenSSL ciphers or 
GnuTLS priority strings. I mention this, because you said the Wget user should 
not be able to set/manage to ciphers by his own. I am not sure how this fits 
into Redhat's philosophy.

> Thank you Tim for the help. I actually renamed the option to
> --with-ciphers-list so the defined list will replace all hard-coded ciphers
> lists regardless if using GnuTLS or OpenSSL.

The above suggested changes are pretty straight forward.
But you may wait for Guiseppe's consent if he will accept such a Redhat 
specific patch at all (but I guess he will ;-).

Regards,Tim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]