Hi, thanks for your thoughts Yoav, apologies for latency,
> I guess my issue with this..
..where "this" is denying the user the capability to "click-through" TLS/SSL
errors/warnings in all error cases..
> ..is because when I read the draft for the first
> time, I thought this would be a good idea for websites that only do HTTPS and
> do not do HTTP except to redirect to HTTPS. I thought it would allow them to
> signal this information, and allow them to defeat HTTP-based MiTM attacks.
Yes, that is exactly the benefit the spec provides.
> The
> draft as it stands is not a good fit for this use case, because it requires
> more of the administrator than is currently reasonable to expect.
If an admin is uncertain about their keeping their TLS/SSL certificate
deployment up-to-date, then they shouldn't declare themselves as an HSTS Host.
And, they shouldn't have themselves listed on Chrome's HSTS pre-loaded list,
nor the upcoming Firefox one.
> I could propose an "HSTS-light" header for this use case, but I don't think
> anybody would like to have that.
Yeah, I'm not sure that's necessary, because what we're talking about here
really is whether the user is offered obvious recourse to proceed with loading
the web app in the face of TLS/SSL errors -- i.e., to be allowed to "click
through" -- and in most (all?) browsers, the user is allowed to recourse to
click through many TLS/SSL errors. So in some sense it is the status quo for a
plain old non-HSTS web app.
In the Paris WG session, the discussion of the above morphed to thinking about
having a new "this site is testing HSTS" directive.
In thinking about this, we don't think it is really necessary because if one
declares one's web app as being HSTS, one can watch server logs to see if any
requests come in over plain http, and then go track those issues down. You
don't really need the user agent's help to figure out what is happening. It's
just going to mechanically transform all http URIs pointing to your site into
https ones, and try to load them, and if they 404, you'll know it (via your logs).
It's arguably different with Content Security Policy (CSP) -- which is where
the discussed notion came from ("report-only") -- because in CSP, the user
agent is enforcing policy on loaded content within itself and there may be no
other way to figure out what it's doing.
HTH,
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
