[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
- [Bug-wget] Wget and Perfect Forward Secrecy, Tim Ruehsen, 2013/08/15
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Tim Ruehsen, 2013/08/15
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Ángel González, 2013/08/15
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Daniel Kahn Gillmor, 2013/08/20
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Tim Ruehsen, 2013/08/21
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Daniel Kahn Gillmor, 2013/08/21
- Re: [Bug-wget] Wget and Perfect Forward Secrecy,
Tim Ruehsen <=
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Daniel Kahn Gillmor, 2013/08/21
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Tim Rühsen, 2013/08/21
- Re: [Bug-wget] Wget and Perfect Forward Secrecy, Tim Ruehsen, 2013/08/22