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: Tomas Hozza
Subject: Re: [Bug-wget] [PATCH] Allow to redefine ciphers list for OpenSSL
Date: Fri, 11 Jul 2014 04:30:04 -0400 (EDT)

----- Original Message -----
> 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.

I think you misunderstood me. My intention was NOT to handle PFS or any other 
method
specially. The intention is to replace ALL occurrences of hard-coded ciphers 
priority
list strings with value defined when running ./configure.

That's why I don't want to introduce 4 new options, but a single one.

> 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

Please see the version 3 of the patch sent along with my previous email. We 
don't
need and don't want to define ciphers list for each method separately, but 
rather
have one global ciphers priority list that will apply to all methods. The most 
viable
place to do this is when compiling wget. 

> 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.

My intention is to contribute a universal patch that will enable us to solve our
use-case using one configure option, while at the same time it will have low 
impact
on the wget itself. Everything will work as before if the option is not used.

> 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.

Well, like Petr pointed out before, of course there are other ways how to
run wget against your own SSL library, etc.. The policy will be defined by the
system administrator. So regular unprivileged user will have to use system 
settings.
However it will still be possible to redefine the list (for the system admin).

While I'm not the owner or initiator of the Fedora Feature, from my point of 
view the purpose
of this effort is to have a single place for admin to define a ciphers priority 
list
for all application globally. Now each application uses its own settings and 
list
which is not really manageable 

> > 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 ;-).

Sure. Thanks for your feedback. If there any other things I should
clarify or change in the contributed code, I'm open to discussion.


Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com



reply via email to

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