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

Re: [SRI] may only be used in documents in secure origins

From: Pete Freitag <pete@foundeo.com>
Date: Wed, 5 Nov 2014 16:48:01 -0500
Message-ID: <CAADZ8V5O70t6294LL-SGADnxVwsnHiFhT-T+CJ5w=gQHtfMBjQ@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: Chris Palmer <palmer@google.com>, Tanvi Vyas <tanvi@mozilla.com>, Frederik Braun <fbraun@mozilla.com>, Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Nov 4, 2014 at 10:22 PM, Michal Zalewski <lcamtuf@coredump.cx>
wrote:

> If it's extra work, I don't think it makes sense. But it doesn't
> really add complexity to permit HTTP origins, right?
>

To the contrary it looks to me like it takes a few lines of additional code
to block the http scheme, see lines 90-103:
https://chromium.googlesource.com/chromium/blink/+/15bd7722d95ee0fd50887d84d75dff570569138b/Source/core/frame/SubresourceIntegrity.cpp#90

This is an interesting debate, even though I was the one to raise this
issue I do see merits to both sides of the issue. I think the hard fail is
a bit too much though, if you want to make a statement then log a console
message about it, this will annoy developers using http.

There are still a number of Google owned domains that do not allow HTTPS,
for example try https to a blogspot.com domain and you will get 302
redirected to http. Here's a good example:
https://googleonlinesecurity.blogspot.com/

HTTP/1.1 302 Moved Temporarily
Location: http://googleonlinesecurity.blogspot.com/
Content-Type: text/html; charset=UTF-8
Date: Wed, 05 Nov 2014 21:37:43 GMT
Expires: Wed, 05 Nov 2014 21:37:43 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

Also note the use of security headers here :)
Received on Wednesday, 5 November 2014 21:48:48 UTC

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