Hi Jeff,
Sorry for even slower response.
On 12/06/2012 08:00, =JeffH wrote:
[...]
> 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).
(Speaking as a WG participant, not as a co-chair.)
I don't think relying just on server side logs is actually a good idea.
You are effectively limiting who is able to debug the problem, which
sometimes can be caused by things outside of direct webserver
administrator control. Existence of "I am testing HSTS" directive would
allow browsers to present debug information on HSTS succeeding/failing
in some form (browser logs, additional debug frame, etc.)
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.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
