bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] [PATCH] Update HSTS info


From: Ander Juaristi
Subject: Re: [Bug-wget] [PATCH] Update HSTS info
Date: Sat, 15 Aug 2015 13:39:47 +0200

No worries ;-)

As I told Tim off list, I'm working on the improvements.

Sent from my smartphone. Excuse my brevity.

---- Darshit Shah escribió ----

>Hi Ander,
>
>Could you please take a look at dkg's suggestions and recreate a patch?
>
>On Mon, Aug 10, 2015 at 9:36 PM, Daniel Kahn Gillmor
><address@hidden> wrote:
>> Hi Ander--
>>
>> Thanks for this!  having the concise, human-readable description of the
>> intended behavior is really useful.
>>
>> a couple comments on the proposed documentation below:
>>
>> On Sat 2015-08-08 13:50:17 -0400, Ander Juaristi wrote:
>>
>>> Those two patches add two extra debug traces for HSTS, and most 
>>> importantly, update the documentation to include information about HSTS.
>>  [...]
>>> address@hidden address@hidden
>>> +By default, Wget stores its HSTS database in @file{~/.wget-hsts}.
>>> +You can use @samp{--hsts-file} to override this. Wget will use
>>> +the supplied file as the HSTS database. Such file must conform to the
>>> +correct HSTS database format used by Wget. If Wget cannot parse the 
>>> provided
>>> +file, the behaviour is unspecified.
>>
>> There is no pointer or reference here to what the "correct HSTS database
>> format used by Wget" is.  providing a brief pointer (e.g. "look at file
>> doc/FOO in the wget source" or "see https://example.org/wget-hsts-db";)
>> would be useful.
>
>I agree. We should supply a sample hsts config file for the users,
>similar to the wgetrc file that is available in the tarball.
>
>>
>>> +Be aware though, that Wget may modify the provided file if any change 
>>> occurs
>>> +between the HSTS policies requested by the remote servers and those in the
>>> +file. When Wget exists, it effectively updates the HSTS database by 
>>> rewriting
>>> +the database file with the new entries.
>>
>> Is it possible that a user would want to decouple reading from
>> (respecting) an HSTS file and writing to it?  some examples:
>>
>>  * A wget process might have no ability to modify the filesystem (e.g.
>>    a constrained wget -O- in a pipeline), but wants to respect a
>>    system-provided HSTS ruleset.  This might want to read an hsts file
>>    without trying to write to it (or at least without raising an error
>>    on an attempted modification).
>>
>This also allows system admins to create a hsts config file in a
>location where the current user does not have write-access.
>
>>  * A wget process used as part of network testing suite might want to
>>    disobey any system-provided HSTS rules (it needs to emulate behavior
>>    of "ignorant" clients), but might also want to collect the HSTS rules
>>    it sees for later review.  This might want to update an hsts file
>>    without trying to respect its contents.
>>
>> I don't know if these use cases warrant the additional option complexity
>> of accomodating them, but it'd be good to make that decision explicitly
>> (sorry if that's already been done and i've just missed the discussion.
>>
>>> +Care is taken not to override possible changes made by other Wget 
>>> processes at
>>> +the same time over the HSTS database. Before dumping the updated HSTS 
>>> entries
>>> +on the file, Wget will re-read it and merge the changes.
>>
>> This sounds like there might still be a race condition where one
>> process's changes get clobbered.  can we make any atomicity guarantees
>> for users who might be concerned about this?
>>
>>> +Using a custom HSTS database and/or modifying an existing one is 
>>> discouraged.
>>> +For more information about the potential security threats arised from such 
>>> practice,
>>> +see section 14 "Security Considerations" of RFC 6797, specially section 
>>> 14.9
>>> +"Creative Manipulation of HSTS Policy Store".
>>
>> I'd normally characterize these threats as "privacy concerns", not
>> necessarily "security concerns".  users of wget might understand them
>> most closely as offering "cookie-equivalent" mechanisms for some
>> http/https clients.
>>
>> sorry these questions and considerations are in text form and not as
>> patches.  feel free to take from them whatever you might find useful.
>>
>> Regards,
>>
>>         --dkg
>>
>
>
>
>-- 
>Thanking You,
>Darshit Shah

reply via email to

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