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

[Tim Ruehsen]

The patches have just been pushed.

Tim

On Tuesday 18 August 2015 21:12:55 Ander Juaristi wrote:
> Hi Daniel,
> 
> I've amended the previous patches based on your feedback. Well, the first
> patch only. I re-attach the second one without modifications.
> On 08/10/2015 06:06 PM, Daniel Kahn Gillmor wrote:
> > 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 have now added a concise description of how the HSTS database should look
> like.
> > Is it possible that a user would want to decouple reading from
> > (respecting) an HSTS file and writing to it?
> 
> During development, neither Tim nor I ever talked about separating read and
> write. It just didn't happen.
> 
> But I guess you're right. There should be a way of separating reads and
> writes. The default behaviour should still be kept the same, but there
> should be a way of decoupling those processes, as you say. It should not be
> prohibitively expensive, and someone might benefit from such features.
> 
> I've been thinking about a couple of possibilities here, based on the
> examples you provided. Discussion starts here ;-)
> 
>      * Make the HSTS database read-only. Load the HSTS entries contained
> there but do not rewrite the file. This could be governed by an extra
> command-line switch, like '--hsts-read-only'. It could be passed together
> with '--hsts-file', for example:
> 
>          wget --hsts-read-only --hsts-file=~/my-fixed-hsts-file
> 
>      * Do not use an HSTS database at all. HSTS would be handled internally
> but there would be no interaction with the file system. Something like
> '--no-hsts-file'.
> 
>      * <Your option here>
> 
> > 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?
> 
> You're right. My fault not to take this into account. This could be fixed
> with flock/fcntl. I think they're both in gnulib.
> 
> These last two issues require code changes. I'll take the responsibility to
> fix them, but outside of GSoC. The first one requires a bit of consensus
> before coding anything, but the second one seems a bit more
> straightforward. For now, I attach the two previous patches. The first one
> (the HSTS docs) amended with dkg's suggestions. If there're no more
> complaints, I think they can be pushed, because Wget's behaviour has not
> changed yet. When we implement any of the ideas proposed above, we'll
> update the docs.
> > 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.
> 
> I think that's a widespread misconception. It's true many users map HSTS to
> HTTP cookies, but IMO that's a mistake. HTTP cookies and HSTS might be
> similar in some aspects, but they're two mechanisms that were designed for
> different purposes. HTTP cookies bridge the gap between HTTP's traditional
> stateless nature, and the stateful needs of modern Internet users. On the
> other hand, HSTS was conceived as a workaround for some security threats.
> It's true that these threats might more specifically target privacy, but I
> think it's an error for us, GNU developers, to keep on feeding the "HSTS ==
> cookie" misconception.
> 
> 
> Regards,
> - AJ