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

[Tim Ruehsen]

On Tuesday 20 August 2013 18:05:45 Daniel Kahn Gillmor wrote:
> On 08/15/2013 04:36 AM, Tim Ruehsen wrote:
> > Maybe a new option like --secure-options=... for expert users would be
> > better than recycling --secure-protocol.
> > wgetrc should have two settings like secureoptionsgnutls and
> > secureoptionsopenssl. For when a user changes these settings and than
> > switches between wget-gnutls and wget-openssl.
> 
> I like this idea.  On the GnuTLS mailing list, it is often encouraged
> for applications which use the library to expose the priority string to
> their users as a setting.

That is good hint, thanks.

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

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.

Regards, Tim