Re: HSTS over HTTP question.

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