Standardize HSTS priming of related origins |
||||||||||||
Issue descriptionRight now, the standard HSTS advice for sites hosted at `https://www.example.com` is to include a 1px image from `https://example.com/img.png` in order to set HSTS for `example.com` with `includeSubDomains`. For example, `www.icloud.com` used to do this, although I can't repro it right now. This is similar to Mike's "HSTS priming" concept [1], except with a single explicit resource. However, there is no standard way to identify the resource for this trick. In addition, I'm told it doesn't work with "third-party" domains in Safari – e.g. you can prime your parent domain, but example.com (and subdomains) can't prime example.net (and subdomains). And because there is no standard advice for priming, a *lot* of sites leave their eTLD+1 un protected. This was a problem 3 years ago [2], and it is still a problem now. To get around this, https://hstspreload.appspot.com/ currently requires an additional redirect: http://example.com -> https://example.com -> https://www.example.com However, the middle redirect is a slight performance penalty. In addition, a direct visit to https://www.example.com (e.g. bookmark, direct link) does not create/update the browser's dynamic HSTS entry for http://example.com. So, we want a mechanism that allows each visit to `https://www.example.com` to be "just as good" for protecting `https://example.com` (and all its subdomains) using HSTS as if the visit were to `https://example.com`. Here's any wishlist: 1. The mechanism should be standardized, ideally in a spec (e.g. IETF). 2. The mechanism should not carry a noticeable performance penalty compared to loading `https://www.example.com` as usual. 3. The mechanism should refresh the check for the ancestor domain on each page load. - The request to the ancestor domain could be served from the cache, though. 4. It should be possible to verify this mechanism using simple scanning code (i.e. without parsing the DOM, or at least without loading the page in a headless browser). 5. The mechanism should be resilient against someone who can tamper with the page content [3]. In practice, I think this means there needs to be a solution that uses only headers. 6. The mechanism should not require special adjustment of CSP. 7. The mechanism works in existing browsers that support dynamic HSTS. 8. The mechanism should not rely on HEAD requests to the ancestor domain (some servers will reject those without sending the right headers). 9. The mechanism does not rely on the server knowing exactly what domain it is (test domains differ from prod domains; advice should be copy-pasteable with as little tweaking as possible). 10. The mechanism should work even if the domains to be primed don't serve an HSTS header from the root path (/). 11. The mechanism should be data-efficient even if the root path resource of any domain to be primed is pretty large (this is usually in conflict with #8). And a bonus: 12. The mechanism allows priming multiple, arbitrary domains that the site operator cares about (e.g. washingtonpost.com can protect wapo.com). Unfortunately, I don't think we can meet nearly all of these at once. Here are some strawman ideas: - Any time the browsers sees an HSTS header, automatically make HEAD requests the root path (/) up the domain ancestor chain all the way up to eTLD+1 (doesn't meet #5, #7, #8, #9, #12). - Cleverly redirect to an ancestor domain and back on some page loads (doesn't meet #2, #3, #8, maybe #4, #5, #9, #12). - Allow the HSTS header to specify additional domains to prime with a HEAD request to the root path (does not meet #7, #8, #9, #10): Strict-Transport-Security: max-age=10886400; includeSubDomains; preload; prime=example.com,blabla.com - To meet #10, allow specifying URLs rather than origins. - To meet #9, introduce special tokens to specify ancestor domains. - Standardize a name and place for a priming resource, ideally in the header (doesn't meet #4, #5, #6, maybe #9 would take some care for #7) - <link rel="hsts-prime" href="https://example.com/prime">? (doesn't meet #7 unless we reuse an existing "rel" type) [1] https://mikewest.github.io/hsts-priming/ [2] https://garron.net/crypto/hsts/hsts-2013.pdf [3] https://chloe.re/2016/06/23/hardening-content-security-policy/
,
Jul 7 2016
A few thoughts:
I don't think we can reasonably allow `sub.domain.tld` to directly set a policy for `domain.tld` (or, for that matter, `tld` itself), as that's not generally the way we assume ownership flows. I would suggest that whatever we come up with would need to obtain permission from the ancestor endpoint.
A strawman that would work today is a link header pointing to (ideally) a well-known resource, or (less-ideally) an application-specific resource:
Link: <https://example.com/.well-known/hsts-prime>; rel="preload"; as="html"
or
Link: <https://dropbox.com/hstsping>; rel="preload"; as="html"
I think it's a good idea to reuse that existing infrastructure rather than inventing something new, and it has the advantage of being deployable right now. We could deal with #4 in the application-specific case by adding a new attribute to the `Link` header which browsers would ~ignore. Perhaps:
Link: <https://dropbox.com/hstsping>; rel="preload"; as="html"; hsts="1"
WDYT?
,
Jul 7 2016
> I would suggest that whatever we come up with would need to obtain permission from the ancestor endpoint. Definitely agreed. I didn't know about link headers; I'll look into that. Thanks for the pointer! :-)
,
Aug 12 2016
,
Aug 12 2016
,
Aug 22 2016
<link> in the <head> working at https://code.garron.us/hsts-priming/link-prefetch/ in Chrome. Still trying to set up a test for a Link: header.
,
Aug 23 2016
Have you been able to characterize how important priming like this is, compared to continuing the work on preloading? If the goal is to get clients to see a eTLD+1 owner's HSTS policy with "includeSubDomains", then that eTLD+1 is also ready for preloading, and should preload. That would make all priming issues moot. I recognize that HSTS preloading can't cover the entire web, and has scaling milestones that will make it challenging. But I wonder whether any of the approaches here -- all of which are opt-in -- will address this problem. If you're creating a new mechanism just for HSTS-enthusiastic site owners to ensure their includeSubDomains policy gets applied, these are the folks who are already going to preload. But more importantly, if you want to have this stem the tide of preloaded entries, you need to know that the less early-HSTS-adopter site owners are going to use what you're proposing as a replacement. I would be concerned that sites whose web servers on their eTLD+1 domain are so enterprise-y as to reject HEAD requests are likely to be invested in HSTS and priming. More immediately, the requirement to have http://example.com redirect internally to https://example.com before redirecting to https://www.example.com only adds dynamic HSTS protection to a very specific class of visits, which is URLs typed in by hand. Links and bookmarks aren't protected at all, and hand-typed domains alone seems like a small category over which to ask site owners to do something awkward and less performant -- particularly when the security benefit is mooted by preloading, which they'll already be in a position to do (having "includeSubDomains" in place). I recommend dropping the requirement to internally redirect to HTTPS before redirecting to a new hostname, and proposing the <link prefetch> approach as an easy (and more performant) best practice for sites to put on their www homepages.
,
Aug 23 2016
> I recommend dropping the requirement to internally redirect to HTTPS before redirecting to a new hostname, and proposing the <link prefetch> approach as an easy (and more performant) best practice for sites to put on their www homepages. I don't completely follow your reasoning for the rest of this, but I agree that this is by far the best. If you have some time, I could use some help finding out a Link:/<link> variant that provides the most benefit across existing browsers without new changes. (I have heard, e.g. that Safari only takes HSTS from subresources if they're "first-party" – something like eTLD+1).
,
Aug 26 2016
,
Aug 26 2016
,
Aug 26 2016
,
Sep 13 2016
Generalizing the bug title. This is more generally applicable. `ww.washingtonpost.com` might want to protect `washingtonpost.com` as well as `wapo.com` and others. This is already possible in most browsers, and we should probably come up with recommendations for non-hacky way to do it in general. If we can do it with Link: headers, we could hopefully (some day) also avoid doing it on every page load by using an origin policy.
,
Sep 21 2016
,
Sep 21 2016
,
Oct 7 2016
I'm not sure whether HSTS falls under DomainSecurityPolicy or SSL, so I'm assigning both. :)
,
Oct 7 2016
Domain Security Policies is sufficient :)
,
Feb 18 2017
Issue 615525 has been merged into this issue.
,
May 26 2018
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by lgar...@chromium.org
, Jul 7 2016