I am not sure whether I agree that that violates the RFC. The connection does fail it just allows the user to override it.
In my opinion, I think that this is the only secure way to "fail" an authenticated HSTS header otherwise anybody could in theory activate HSTS on a host. The same paragraph then goes to on to say that if you want to use a HSTS policy with the host then distribute the CA certificate and then of course it works as expected with No User Recourse. Kind Regards, Scott First Class Watches 9 Warwick Road Kenilworth CV8 1HD Warwickshire United Kingdom On 9 October 2014 22:27, Eddie B <ed...@mattermedia.com> wrote: > The cert is self signed. Whats is the conclusion, chrome is violating the > RFC? It DOES let me proceed. > > On 10/6/14 5:52 PM, Scott (firstclasswatches.co.uk) wrote: > > Hello, > > > > Not strictly a httpd specific issue but nevertheless, Chrome/Firefox > > should ignore the header because it is not delivered with a valid > > certificate and thus there is no way of knowing if it was actually > > issued by the website. > > Spec says in this exact case, the TLS connection should be refused: > http://tools.ietf.org/html/rfc6797#section-11.3 > > > You should get the expected result if you first respond with an HSTS > > header in a valid TLS request and then /future/ requests should be > > prevented from proceeding if there is a certificate error. > > > > This is why HSTS are being preloaded for major websites as that would > > to cover the first request. For your average website there isn't > > currently a solution to this. > > - -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
