[Top][All Lists]

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

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

From: Tim Ruehsen
Subject: Re: [Bug-wget] Wget and Perfect Forward Secrecy
Date: Wed, 21 Aug 2013 16:45:05 +0200
User-agent: KMail/4.10.5 (Linux/3.10-2-amd64; KDE/4.10.5; x86_64; ; )

On Wednesday 21 August 2013 10:15:05 Daniel Kahn Gillmor wrote:
> On 08/21/2013 03:10 AM, Tim Ruehsen wrote:
> > On Tuesday 20 August 2013 18:05:45 Daniel Kahn Gillmor wrote:
> >> On 08/15/2013 04:36 AM, Tim Ruehsen wrote:
> >>> Beside this 'expert' option, there should be a an 'everyones' option to
> >>> force/enable PFS, using --secure-protocol as I already suggested.
> >> 
> >> My only concern about this is what a mirroring/recursive wget would do
> >> if it encountered an http:// or ftp:// link within its initial https://
> >> fetch.  Would wget --secure-protocol refuse to fetch the cleartext link
> >> (thereby failing to fully mirror), or would it go ahead and fetch it
> >> (thereby failing to require a secure protocol)?
> > 
> > This is a bit OT, since I don't want to change Wget's download algorithm.
> > 
> > It would a different issue, but FYI:
> > If the parent page was HTTP/HTTPS Wget would not follow ftp:// links
> > (except requested by --follow-ftp).
> > But yes, insecure HTTP URLs will be followed, even if the parent is HTTPS,
> > as long as they are on the same host/domain (behaviour can also be
> > changed by -H and/or --domains).
> i think i didn't make myself very clear here, or maybe i didn't
> understand your original proposal.  I (think i) already understand the
> standard wget mirroring algorithm.  My point is that --secure-protocol
> as a choice of option name risks implying to the user that all downloads
> will be done with a secure protocol, which we know is not the case.  or
> are you suggesting something like --secure-protocol=PFS ?  that doesn't
> seem properly orthogonal, since a user might want to indicate which
> version(s) of SSL/TLS they want to support *and* enforce PFS where possible.

I suggested two options

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.

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.

> > Have a look into recur.c/download_child_p() more detailed information.
> > For a new option to not change the protocol from secure to insecure, you
> > could easily extend the code.
> Yes, an --https-only mode would be pretty cool, regardless of whether
> the user wants to force PFS.
> Thanks for thinking this through, having these options would be pretty
> great.

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 ?

Regards, Tim

reply via email to

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