From wilander@apple.com Tue Jan 30 13:51:49 2018 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E181309F4 for ; Tue, 30 Jan 2018 13:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeLMMaUlc_M2 for ; Tue, 30 Jan 2018 13:51:47 -0800 (PST) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07AE131101 for ; Tue, 30 Jan 2018 13:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1517349106; x=2381262706; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0JfYyI5XVEmYrJs7nhm0rnu9WAmiSlCnppukiPuQmzQ=; b=sjGouyVtWq4Z+v8t22x2rly6wmOffuQRpFHXHb0hISpaSvA8DxiN82qletu88QY2 f8vPpXhp8RkUTuNIOpVmLY1Uq06E3Cp0KeEh6/oNAQOuCmylSbqdEl1L8BZQGwQd 4wh/yLrdjSc26usPnNU/DMMnm1NQ6a4/+i/C97OrTX7P+ZP2L6RBbqspriR5Ivh/ KtCwnskWr2ALvNBa/qEaV9y8MFAvj1Mj7c8L94k395JDgyugX4wqCBpUqG5pt5AO pkNwwArQ/KPRHchvNBHgjZH4VQaxSrPh1KUbBnVgdWSS1bSwOqnt9whV5KC62TvO 1a108sSaVHQ/u4Hj+7OzqA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 8C.C9.10828.2F8E07A5; Tue, 30 Jan 2018 13:51:46 -0800 (PST) X-AuditID: 11ab0218-260a89e000002a4c-ec-5a70e8f2fec1 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay8.apple.com (Apple SCV relay) with SMTP id 50.4E.22651.2F8E07A5; Tue, 30 Jan 2018 13:51:46 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XNJwh7xvKnfyzJ9pDgzPoQ)" Received: from [17.202.48.94] (unknown [17.202.48.94]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.1.20180104 64bit (built Jan 4 2018)) with ESMTPSA id <0P3E008N622ATL90@nwk-mmpp-sz09.apple.com> for websec@ietf.org; Tue, 30 Jan 2018 13:51:46 -0800 (PST) Sender: wilander@apple.com From: John Wilander Message-id: Date: Tue, 30 Jan 2018 13:51:45 -0800 To: websec@ietf.org X-Mailer: Apple Mail (2.3445.6.7) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCYpvvpRUGUwfO7Vhan5y1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxonblxkL5stVPNl6lLGBcb5UFyMnh4SAicTNC33sXYxcHEIC a5kkepr2s8IkZu6/wAyROMgo8XHpdTaQBK+AoMSPyfdYQGxmgTCJL+8ms0IULWaS2DttDztI QlhASuL6tM9MIDabgIbEilUL2CDiKhLLny4GauAAGmQj8eMMN0iYRUBVYsPhDnaQsIiAsMTi LzUQNyhKND/5BDZeQuApq8Tab3PZJjDyz0JyxiwkZ8wCamcWUJeYMiUXIqwt8eTdBVYIW01i 4e9FTMjiCxjZVjEK5yZm5uhm5hmZ6CUWFOSk6iXn525iBIXraiaJHYxfXhseYhTgYFTi4eWo KIgSYk0sK67MPcQozcGiJM4bqZwVJSSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx1n6e7n+n jacEGCRdW78ms78m+2XRyodHRb7y3le4E5I+R0bFfOmKx+kasVwnTgYGc6hF7xSwVVHq2V0a /XHeX0chS0uJVaKrhZYnzFe5nfvmFevarj0P7pYrPXP1Uu4TM7Rp+JvIGSs0x+pDpfqsz0sn /HrEu/N5bkrbaxkWqUpx12XM87OUWIozEg21mIuKEwES+be3OAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUi2FAcoPvpRUGUwabNWhan5y1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxonblxkL5stVPNl6lLGBcb5UFyMnh4SAicTM/ReYuxi5OIQE DjJKfFx6nQ0kwSsgKPFj8j0WEJtZIEziy7vJrBBFi5kk9k7bww6SEBaQkrg+7TMTiM0moCGx YtUCNoi4isTyp4uBGjiABtlI/DjDDRJmEVCV2HC4gx0kLCIgLLH4Sw3EDYoSzU8+sU5g5JmF ZPMsJJtnAXUwC6hLTJmSCxHWlnjy7gIrhK0msfD3IiZk8QWMbKsYBYpScxIrLfQSCwpyUvWS 83M3MYKDqzBtB2PTcqtDjAIcjEo8vBwVBVFCrIllxZW5hxglOJiVRHhFVudHCfGmJFZWpRbl xxeV5qQWH2KU5mBREud9xZMbJSSQnliSmp2aWpBaBJNl4uCUamAsz8lPdA9LVMrf2fize3Xa qTPSsYcerniZcdvnis9lpwttSeX+/o0dGyff6b379Pn2mNV1J1+IFtRPb1P6qM3BnS7eVhOw uGljjciJhDm3n7wpmK72+XlwwVbV2QdN7/BM9z+ukMzkw3ahzVst+XbGukeZv3zPxurM6DJt nezXe1hcL9E+86ISS3FGoqEWc1FxIgAeMKp7KgIAAA== Archived-At: X-Mailman-Approved-At: Mon, 05 Feb 2018 08:08:26 -0800 Subject: [websec] Safari restrictions to HSTS X-BeenThere: websec@ietf.org 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: Tue, 30 Jan 2018 21:53:38 -0000 --Boundary_(ID_XNJwh7xvKnfyzJ9pDgzPoQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi WebSec @ IETF! My name is John Wilander and I=E2=80=99m a security engineer on = Apple=E2=80=99s WebKit team. WebKit, and thus our browser Safari, has = some special rules for (non-preload) HSTS to mitigate HSTS super = cookies. I=E2=80=99m sending over the details in case you want to = augment the HSTS specification. Basic rule: Only allow first parties to set HSTS. If it=E2=80=99s 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=E2=80=99s 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 https://sub.domain.example.com = . A response to a subresource request = on that page may set HSTS for: sub.domain.example.com and example.com It may not set HSTS for: some.sub.domain.example.com , domain.example.com , or other.org Kind regards, John Wilander= --Boundary_(ID_XNJwh7xvKnfyzJ9pDgzPoQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi WebSec @ IETF!

My name is John Wilander and I=E2=80=99m = a security engineer on Apple=E2=80=99s WebKit team. WebKit, and thus our = browser Safari, has some special rules for (non-preload) HSTS to = mitigate HSTS super cookies. I=E2=80=99m sending over the details in = case you want to augment the HSTS specification.

Basic rule: Only allow first parties to = set HSTS.

If = it=E2=80=99s 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=E2=80=99= 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 https://sub.domain.example.com. A response to a = subresource request on that page may set HSTS for:
  1. sub.domain.example.com and
  2. example.com
It may not set HSTS for:
  1. some.sub.domain.example.com,
  2. domain.example.com, = or
  3. other.org
   Kind = regards, John Wilander
= --Boundary_(ID_XNJwh7xvKnfyzJ9pDgzPoQ)-- From nobody Mon Feb 5 13:59:08 2018 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BC8127011 for ; Mon, 5 Feb 2018 13:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lxZLmv7mRNk for ; Mon, 5 Feb 2018 13:59:04 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DAB1241F8 for ; Mon, 5 Feb 2018 13:59:04 -0800 (PST) Received: by mail-yw0-x233.google.com 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; d=chromium.org; 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; d=1e100.net; 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 10.37.162.135 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 Cc: websec@ietf.org Content-Type: multipart/alternative; boundary="089e0828aad89100c605647e2be5" Archived-At: Subject: Re: [websec] Safari restrictions to HSTS X-BeenThere: websec@ietf.org 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 --089e0828aad89100c605647e2be5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 longsitename.example: - http://short.example - Redirect - https://longsitename.example (Real-world examples: fb.me, bofa.com, bit.ly, t.co) 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 =E2=80=93 this will not work if short.ex= ample 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 site: - http://short.example - Redirect - https://short.example - Set HSTS - Redirect - https://longsitename.example In fact, https://hstspreload.org/ 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 =E2=80=93 = 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.) =C2=BBLucas On Mon, Feb 5, 2018 at 8:08 AM John Wilander wrote: > Hi WebSec @ IETF! > > My name is John Wilander and I=E2=80=99m a security engineer on Apple=E2= =80=99s WebKit > team. WebKit, and thus our browser Safari, has some special rules for > (non-preload) HSTS to mitigate HSTS super cookies. I=E2=80=99m sending ov= er the > details in case you want to augment the HSTS specification. > > Basic rule: Only allow first parties to set HSTS. > > If it=E2=80=99s a response to a top frame load that has an HSTS header, i= t is > obviously the first party so that's automatically handled. If it=E2=80=99= 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 https://sub.domain.example.com. A > response to a subresource request on that page may set HSTS for: > > 1. sub.domain.example.com and > 2. example.com > > It may not set HSTS for: > > 1. some.sub.domain.example.com, > 2. domain.example.com, or > 3. other.org > > Kind regards, John Wilander > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > --089e0828aad89100c605647e2be5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I think it is is good to fight supercookies, I&= #39;d like to note that this kind of policy has performance implications.

Suppose a site has a domain named short.example tha= t redirects to longsitename.example:
(Real-world examples: fb.me, bofa.com, bit.ly, t.co)

Neither step in the redirect can set an HSTS header fo= r the short.example host, which means that subsequent visits will not be pr= otected. 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 bro= wsers more easily) and usually only applies to exact URLs =E2=80=93 this wi= ll not work if short.example is e.g. a URL shortener with different URLs fo= r different visits.

It is possible to fix this by = redirecting to HTTPS before going to another site:
In fact,=C2=A0https://hstspreload.org/=C2= =A0currently enforces this as a dynamic HSTS best practice if you want to s= ubmit short.example to the HSTS preload list.
However, for dynami= c HSTS this incurs the performance penalty of an additional synchronous blo= cking HTTPS request for the first load =E2=80=93 and back when I was mainta= ining the preload list I received a few concerned emails about this penalty= . (Note that the performance penalty goes away for users who have short.exa= mple in their browser's HSTS preload list. But there is a multi-week ga= p while this affects all users before the preloaded site reaches their brow= ser, 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=C2=A0https://longsitename.example=C2=A0is permit= ted to set HSTS for=C2=A0short.example, this has two benefits:
  • http://short.examp= le always gets users to the final destination without a performance pen= alty.
  • All=C2=A0visits to https://longsitename.example can "prime&qu= ot; HSTS for=C2=A0short.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 req= uesting extra subresources, although it would be nice to = have something more declarative.

    I think it wo= uld be nice if any cross-domain restrictions did not introduce dynamic HSTS= security vs. performance tradeoffs for legitimate use cases like I describ= ed.

    One hacky way to solve this for my main exampl= e would be to allow HTTP responses to set an HSTS header for the domain whi= le 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-do= main priming.)

    =C2=BBLucas
    <= /div>
    On Mon, Feb 5, 2018 at= 8:08 AM John Wilander <wilander@apple.com> wrote:
    Hi WebSec @ IETF!

    My name is John Wilander and I= =E2=80=99m a security engineer on Apple=E2=80=99s WebKit team. WebKit, and = thus our browser Safari, has some special rules for (non-preload) HSTS to m= itigate HSTS super cookies. I=E2=80=99m sending over the details in case yo= u want to augment the HSTS specification.

    Basic ru= le: Only allow first parties to set HSTS.

    If it=E2= =80=99s a response to a top frame load that has an HSTS header, it is obvio= usly the first party so that's automatically handled. If it=E2=80=99s a= response to a subresource request, it gets more interesting.
    As of our latest releases, we only allow the current first-part= y domain and its eTLD+1 (formally public suffix + 1) to set HSTS in subreso= urce responses.

    Example:

    = Say you have loaded a page from=C2=A0https://sub.domain.example.com. A response to a = subresource request on that page may set HSTS for:
    1. sub.domain.example.com=C2=A0a= nd
    2. example.com=
    It may not set HSTS for:
    1. some.sub.domain.example.com,<= /li>
    2. domain.exam= ple.com, or
    3. othe= r.org
    =C2=A0 =C2=A0Kind regards, John Wilander
    _______________________________________________
    websec mailing list
    websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
    --089e0828aad89100c605647e2be5--