Re: [Bug-wget] Wget and Perfect Forward Secrecy

[Tim Rühsen]

Am Mittwoch, 21. August 2013, 11:40:09 schrieb Daniel Kahn Gillmor:
> On 08/21/2013 10:45 AM, Tim Ruehsen wrote:
> > 1. --secure-protocol=PFS (or whatever we agree on) for "everyone" (users
> > that have no or not enough knowledge about GnuTLS/OpenSSL option
> > strings). As the other --secure-protocol types (like e.g. 'auto'), this
> > would map to a fixed option string.
> 
> if what if a user wanted to both (a) negotiate PFS and (b) exclude SSLv2
> and SSLv3 ? Could they do that using --secure-protocol or would they
> need to graduate to fancier configurations?

[AFAIK, GnuTLS doesn't support SSLv2 anyways]

He would need the fancier option like
        --gnutls-options=NORMAL:-VERS-SSL3.0:-RSA

Maybe he also wants to disable less secure cipher algorithms and do something 
like
        --gnutls-options=SECURE128:+SECURE256:-VERS-SSL3.0:-RSA.

I tend to say --secure-protocol and --gnutls-options/--openssl-options would 
be mutually exclusive. But then, we could say, if the option starts with '-' 
or '+', it is appended to the internal option string selected by --secure-
protocol. But in this case you should know about Wget internals... who really 
does ?

OpenSSL is similar (but not exactly the same), please re-read my first two 
postings. There you can also find references and explanations, e.g. why 
separate Wget options (GnuTLS and OpenSSL) may make sense.


> 
> > 2. (to be discussed) --gnutls-options=<GnuTLS option string> and/or
> > --openssl- options=<OpenSSL option string> for "experts". Here you can
> > give your own idea of an option string. You can put these into
> > /etc/wgetrc or ~/.wgetrc as default and override them via command line
> > whenever the need arises.
> If wget offers both 1 and 2, how would the two options interact if used
> together?
> 
> I'm asking these questions to try to illuminate what i think are the
> corner cases of the ideas, not because i think the ideas are bad ideas.
>  i like them both, and want to see them work sensibly :)

Good to know.

> > I guess your suggestion of an --https-only mode fits into the current
> > security discussion and I like it. I am pretty sure, people will use it.
> > 
> > I would like to wait another week or so for feedback before I start
> > creating a patch (for my two points above). Are you going to implement
> > --https-only ?
> i'm afraid i don't have time to implement --https-only in the forseeable
> future, sorry :(

Come on, is just a little exercise :-)
You will get some practice... I give you a hand.

Regards, Tim

signature.asc
Description: This is a digitally signed message part.