[websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not)

[Alexey Melnikov <[e-mail]>]

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.