- From: Jacob Hoffman-Andrews <jsha@twitter.com>
- Date: Wed, 19 Mar 2014 23:27:08 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Received on Thursday, 20 March 2014 06:37:53 UTC
I think SRI could be a useful addition to a hardened full-HTTPS implementation that has to use CDNs for scale or performance reasons. Twitter's in exactly this position: We serve JS off of CDNs, which puts an upper bound on our security. For instance, Twitter has certificate pinning for our main domains, twitter.com + api.twitter.com. We trust three CAs for those hosts. However, for our CDN domains *.twimg.com, our CDNs issue the certs from their preferred CAs. That means we have to pin to a much wider set of CAs for those domains, which weakens our overall security, since a compromise on *.twimg.com means a compromise on twitter.com. If we could add SRI to JS from *.twimg.com, we would not be as dependent on the security of those additional CAs, nor would we need to trust our CDNs not to serve poisoned JS. I've heard some talk about using SRI with HTTP resources, with user agents possibly bypassing mixed content checks in that situation. I think bypassing mixed content checks would be a bad idea, since SRI does not provide the confidentiality that HTTPS is supposed to provide.
Received on Thursday, 20 March 2014 06:37:53 UTC