Tomas Hozza <[email protected]> writes: > ----- 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
I think we should still enable users to override these settings through .wgetrc and if the users doesn't specify anything there, then use the value passed to configure. Thanks, Giuseppe
