- From: Ingo Chao <ichaocssd@googlemail.com>
- Date: Sun, 9 Mar 2014 09:52:32 +0100
- To: public-webappsec@w3.org
On Fri, Mar 7, 2014 at 9:26 PM, Daniel Veditz <dveditz@mozilla.com> wrote: > On 3/7/2014 6:28 AM, Ingo Chao wrote: >> >> I am aware of 6.2. HTTP Request Type >> A HSTS Server MUST NOT include the Strict-Transport-Security HTTP >> Response Header in HTTP responses conveyed over a non-secure >> transport. >> >> But I don't understand the reasons. > > > Because we don't trust the connection. Adding HSTS to a site not prepared to > be fully TLS results in a denial of service for that site that the user > won't really understand or easily fix. > > -Dan Veditz On Fri, Mar 7, 2014 at 5:40 PM, Adam Langley <agl@google.com> wrote: > On Fri, Mar 7, 2014 at 9:28 AM, Ingo Chao <ichaocssd@googlemail.com> wrote: >> - the HSTS is ignored when received via HTTP > > It should be. Which browser do you believe is getting this wrong? > > > Cheers > > AGL Thanks for your answers. I think what happend here was: 1 GET http://www.example.com 2 GET https://www.example.com/cssasset.css [ <-response contains Strict-Transport-Security:max-age=86400] 3 XMLHttpRequest to http -> https://www.example.com/jsasset.js Chrome's console said: "XMLHttpRequest cannot load https://www.example.com/jsasset.js No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.example.com' is therefore not allowed access." By mistake, the 2nd request was a GET HTTPS and the response contained a HSTS. Consecutively, the following XMLHttpRequest was blocked because the received HSTS urged the browser to load this jsasset via https, but this is permitted by same origin policy. Since the connection 1 was untrusted, but 2 was a trusted one, the HSTS landed in 2 and caused 3 to fail. Of course this was my mistake, sorry. Thanks, Ingo
Received on Sunday, 9 March 2014 08:52:59 UTC