Re: [Bug-wget] [PATCH] Trivial changes in HSTS

[Tim Ruehsen]

Hi Ander,

just pushed 0002 and 0003. 

> You're right, but the downside is that it could cause a denial of
> service. I was being driven by section 14.5 of RFC 6797. If another user
> modifies your HSTS file and puts a server that does not have HTTPS
> enabled, then you won't be able to contact that server, because wget
> will attempt to do it via HTTPS all the time.

Yeah, let's do it your way.

Did you consider Giuseppe's suggestion ?
"can the file_exists_p check just be moved to hsts_file_access_valid that
doesn't return an error on ENOENT?  In other words, just have here:
if (hsts_file_access_valid (filename))"

Tim

On Friday 08 April 2016 22:33:37 Ander Juaristi wrote:
> Hi Tim,
> 
> You're right, but the downside is that it could cause a denial of
> service. I was being driven by section 14.5 of RFC 6797. If another user
> modifies your HSTS file and puts a server that does not have HTTPS
> enabled, then you won't be able to contact that server, because wget
> will attempt to do it via HTTPS all the time.
> 
> WDYT?
> 
> On 07/04/16 12:52, Tim Ruehsen wrote:
> > On Wednesday 06 April 2016 14:31:17 Juaristi Álamos, Ander wrote:
> >> Hi all,
> >> 
> >> Here are some patches for HSTS.
> >> 
> >>   - 0001: checks the HSTS database file is not world-writable, and
> >> 
> >> refuses to read it if it is, and disables HSTS. This was in my original
> > 
> > Doesn't it make sense to share the HSTS database globally ? It is
> > basically
> > global data (domain specific) and not user specific.
> > 
> > Thinking forward, a central (trusted) database/daemon for HSTS entries
> > would be nice - sooner or later almost any domain supports HSTS. Each
> > process loading/saving a huge file would not be efficient.
> > 
> > Same goes for e.g. cert pinning (but not for cookies which are private
> > data).
> > 
> > Regards, Tim

signature.asc
Description: This is a digitally signed message part.