W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: HSTS over HTTP question.

From: Brian Smith <brian@briansmith.org>
Date: Sun, 9 Mar 2014 15:45:30 -0700
Message-ID: <CAFewVt58j8h1x9U=WdjumRpa+B_zkpARB_tem2hkXkNz+K_5-Q@mail.gmail.com>
To: Ingo Chao <ichaocssd@googlemail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Sun, Mar 9, 2014 at 12:52 AM, Ingo Chao <ichaocssd@googlemail.com> wrote:

>
>   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.
>

Hi,

In your message you imply that your mistake was making the HTTPS request to
https://www.example.com/cssasset.css. but, there is a more fundamental
mistake. If you're going to use HSTS, then you really should never serve
anything from the non-HTTPS origin except redirects to the HTTPS origin. If
the response to the first request to http://www.example.com/ would have
been a permanent redirect to https://www.example.com/ then the same-origin
policy violation would not have occurred. If you don't consistently
redirect HTTP -> HTTPS then you'll end up with race conditions like the one
you experienced. Further, serving anything other than redirects ends up
ultimately undermining the security advantages that HSTS gives you.

Similarly the XMLHttpRequest to
http://www.example.com/jsasset.js<https://www.example.com/jsasset.js>.
should have been to https://www.example.com/jsasset.js. Similarly to #2,
HSTS is more effective as a security mechanism when you consistently use
https:// URLs instead of depending on HSTS to rewrite your URLs.

Cheers,
Brian
Received on Sunday, 9 March 2014 22:45:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC