Re: [websec] Safari restrictions to HSTS

Lucas Garron <> Mon, 05 February 2018 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7BC8127011 for <>; Mon, 5 Feb 2018 13:59:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8lxZLmv7mRNk for <>; Mon, 5 Feb 2018 13:59:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32DAB1241F8 for <>; Mon, 5 Feb 2018 13:59:04 -0800 (PST)
Received: by with SMTP id x62so19507253ywg.11 for <>; Mon, 05 Feb 2018 13:59:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6LuKi4PTYLcsy4HXNSJsCckOc6ILZsuim6UXBm+eHQM=; b=Osb6fewcyx4T1viGpGAyredY2S9g3h+EEhdxWy2DvVKxAPHOU4llUsRI1O6ojuoOE/ GW0Nyq7L5C1ZnqQimMrlz0tsCC+K3uVn53vQCTaofaHrcQZvws6lAhmTeQ6BUiozOQQa f8Z2eKyuVzjzkAf6pwYu5eQwgvxwqUwBj1XDg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6LuKi4PTYLcsy4HXNSJsCckOc6ILZsuim6UXBm+eHQM=; b=l6I1/9arC7Rm4gN1pVVOBc2iHcPNPPm0sHBxmKDPd1AWYWnMa/u98aTVYcoM5rh877 FUc44TL6JknbCgrgYy1FLrrLliPGf3kWxnhE/pE1ep4usFk6G4SYydwwkWG2n5LvF55J 5nVDBAsFW3RmBoiCHZTu1pxTlBNIORs7XYXJcIIjxjwXkneEPdVAeO++Z7NaW3+75Kzy AHaWqkJgnNzeAw8SVk2W11txuZAcwym8omjaBoNdg+ebL/zCWSLWzsitKcVyVA/lTyyy NzE1brAnBZ2A5PWGGqXqc5QuHFz499+M86isLZH7hc6Z5J7GIrV2faGkTDKAYKjek2e/ TalA==
X-Gm-Message-State: APf1xPBEPG00ZGB8ioDF+xsNcwn8lf6Vva+LZw6R2aZtR2Q3aNnK5Pxw 8/6ngOFK64OlJwUkzN0o2HovYtV62Rj1l+xmsOpqZg==
X-Google-Smtp-Source: AH8x226hLOR+0gGdOwEGgqCqm8aUCY3EgjSQKdwG+zevVDCjh84nnVIllruhUC2h71MAAUic9ROhh89UsKOsCfmfuD0=
X-Received: by with SMTP id c7mr178610ybi.247.1517867943127; Mon, 05 Feb 2018 13:59:03 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Garron <>
Date: Mon, 05 Feb 2018 21:58:52 +0000
Message-ID: <>
To: John Wilander <>
Content-Type: multipart/alternative; boundary="089e0828aad89100c605647e2be5"
Archived-At: <>
Subject: Re: [websec] Safari restrictions to HSTS
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Feb 2018 21:59:07 -0000

While I think it is is good to fight supercookies, I'd like to note that
this kind of policy has performance implications.

Suppose a site has a domain named short.example that redirects to

   - http://short.example
      - Redirect
   - https://longsitename.example

(Real-world examples:,,,

Neither step in the redirect can set an HSTS header for the short.example
host, which means that subsequent visits will not be protected. Caching or
using permanent redirect codes can help, but are not as strong as HSTS (the
site's caching max-age may not be as high, may be cleared with browsing
data more easily, or may be evicted from cache by browsers more easily) and
usually only applies to exact URLs – this will not work if short.example is
e.g. a URL shortener with different URLs for different visits.

It is possible to fix this by redirecting to HTTPS before going to another

   - http://short.example
   - Redirect
   - https://short.example
   - Set HSTS
      - Redirect
   - https://longsitename.example

In fact, currently enforces this as a dynamic HSTS
best practice if you want to submit short.example to the HSTS preload list.
However, for dynamic HSTS this incurs the performance penalty of an
additional synchronous blocking HTTPS request for the first load – and back
when I was maintaining the preload list I received a few concerned emails
about this penalty. (Note that the performance penalty goes away for users
who have short.example in their browser's HSTS preload list. But there is a
multi-week gap while this affects all users before the preloaded site
reaches their browser, and this will always affect users with clients that
don't have an up-to-date HSTS preload list. Also, we may soon see a feature
where not all sites on the preload list are shipped to all browser users.)

If the response from https://longsitename.example is permitted to set HSTS
for short.example, this has two benefits:

   - http://short.example always gets users to the final destination
   without a performance penalty.
   - *All* visits to https://longsitename.example can "prime" HSTS
   for short.example in case visitors use it in the future.
      - In fact, the main site can pre-emptively prime HSTS for *multiple*
      related sites without adding redirect hops for each one.

This is currently possible in browsers other than Safari by requesting
extra subresources, although it would be nice to have something more
declarative <>.

I think it would be nice if any cross-domain restrictions did not introduce
dynamic HSTS security vs. performance tradeoffs for legitimate use cases
like I described.

One hacky way to solve this for my main example would be to allow HTTP
responses to set an HSTS header for the domain while redirecting to another
domain, but this contradicts the current spec and makes it easy to brick a
site. (It would also not support general cross-domain priming.)


On Mon, Feb 5, 2018 at 8:08 AM John Wilander <> wrote:

> Hi WebSec @ IETF!
> My name is John Wilander and I’m a security engineer on Apple’s WebKit
> team. WebKit, and thus our browser Safari, has some special rules for
> (non-preload) HSTS to mitigate HSTS super cookies. I’m sending over the
> details in case you want to augment the HSTS specification.
> Basic rule: Only allow first parties to set HSTS.
> If it’s a response to a top frame load that has an HSTS header, it is
> obviously the first party so that's automatically handled. If it’s a
> response to a subresource request, it gets more interesting.
> As of our latest releases, we only allow the current first-party domain
> and its eTLD+1 (formally public suffix + 1) to set HSTS in subresource
> responses.
> Example:
> Say you have loaded a page from A
> response to a subresource request on that page may set HSTS for:
>    1. and
>    2.
> It may not set HSTS for:
>    1.,
>    2., or
>    3.
>    Kind regards, John Wilander
> _______________________________________________
> websec mailing list