Re: HSTS preload flaw

Austin Wright <aaa@bzfx.net> Sun, 09 February 2020 23:51 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8938E120089 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 9 Feb 2020 15:51:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net
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 noD9fopcrLUr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 9 Feb 2020 15:51:30 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 CE825120071 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 9 Feb 2020 15:51:29 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1j0wJ2-0003GK-Ke for ietf-http-wg-dist@listhub.w3.org; Sun, 09 Feb 2020 23:48:04 +0000
Resent-Date: Sun, 09 Feb 2020 23:48:04 +0000
Resent-Message-Id: <E1j0wJ2-0003GK-Ke@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <aaa@bzfx.net>) id 1j0wIx-0003BI-HN for ietf-http-wg@listhub.w3.org; Sun, 09 Feb 2020 23:47:59 +0000
Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <aaa@bzfx.net>) id 1j0wIu-0008AT-Cn for ietf-http-wg@w3.org; Sun, 09 Feb 2020 23:47:59 +0000
Received: by mail-pf1-x433.google.com with SMTP id j9so2774764pfa.8 for <ietf-http-wg@w3.org>; Sun, 09 Feb 2020 15:47:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YnLFoO9alC83dIpHg6i9aMExoVBir7kVUR3fYrtybCM=; b=t1hkQqzhq0lH8HVDOlhDfRFmiSEM4Ectb7b2GTw5NNO1IVYp/hqSifooFdZvMjA77J 6W1BHMy/ZwbSdlPWTDS/OJWRjImtE6B87WInfA2DUSPuzhCPTZ1/DZyViNILwZ005Lz5 Q3xK1m4dwCLIxdDqShy6ZzP1BtQARPbfT5JOc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YnLFoO9alC83dIpHg6i9aMExoVBir7kVUR3fYrtybCM=; b=BxJWGd6p+eGQdwbaLarKPJ1u0RiQQq2l/ajFKBUu79p3XJ6udUbpNmTYOGPDnjt3IJ +EtNZhjyplRkDmMF8GzVnmgQ5wvxKLx42pQdHhxg4EURXH5OdKp1IZevGwzk3iku1KpX FcD5K8GfYZS8b/Mq4JUgDhb3yjtEH54a2r8yWTI8oEo0kPWmQQnGMI/whnoH3FyePdP3 /eC8Em27Y6IpuKBVL3sUmcSl3B4Wt3hM7DF/47AzGE+ogbOQTS3exyomwXeVhWgnGLhB +eRRWNlH2+RpBKMHBXzFR/RMEFItZV4yoWAjpyuVQ7fEACYWLj3PStrOOkMs1hSZm83B Hh3A==
X-Gm-Message-State: APjAAAXkbGeYuaSG0jV8d3HhFvWs0eZUG0u1cZFIrgB7Fc6c4196CAno mE+qbD5CeiWI8lz6y37h8EYJTXdT2PM=
X-Google-Smtp-Source: APXvYqz51H8UAnVNUpAvmZ4bUozemnCOgu+kjZZ2y+oWx8usk1b9+PpPMlNi/9XiCAPnlOSzVMBsOA==
X-Received: by 2002:a63:3751:: with SMTP id g17mr11414096pgn.150.1581292072864; Sun, 09 Feb 2020 15:47:52 -0800 (PST)
Received: from [192.168.0.116] (71-223-240-170.phnx.qwest.net. [71.223.240.170]) by smtp.gmail.com with ESMTPSA id i27sm9971874pgn.76.2020.02.09.15.47.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Feb 2020 15:47:52 -0800 (PST)
From: Austin Wright <aaa@bzfx.net>
Message-Id: <2F2F0B6A-8FD5-459E-9395-FD0437A9E946@bzfx.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D00425D7-385A-442E-9C2D-3E1BBF1CCF31"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Sun, 09 Feb 2020 16:47:46 -0700
In-Reply-To: <CAChr6SyG56wDh=EvEmMUzOfK5YWP3yhrQkXpmWx9MYe9BsghSw@mail.gmail.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
To: Rob Sayre <sayrer@gmail.com>
References: <CAChr6Syfo-XpN0i4O0==G29KJ22oCvq+X_nbjgq8aAhtCR7BzA@mail.gmail.com> <A0F7BEB8-C236-429B-94F7-C2F748FDD70C@bzfx.net> <CAChr6SyG56wDh=EvEmMUzOfK5YWP3yhrQkXpmWx9MYe9BsghSw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Received-SPF: pass client-ip=2607:f8b0:4864:20::433; envelope-from=aaa@bzfx.net; helo=mail-pf1-x433.google.com
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1j0wIu-0008AT-Cn e89dcf79dda1aaedb4a88bc504e47fbe
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HSTS preload flaw
Archived-At: <https://www.w3.org/mid/2F2F0B6A-8FD5-459E-9395-FD0437A9E946@bzfx.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37345
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> On Feb 9, 2020, at 02:30, Rob Sayre <sayrer@gmail.com> wrote:
> 
> On Sun, Feb 9, 2020 at 12:05 AM Austin Wright <aaa@bzfx.net <mailto:aaa@bzfx.net>> wrote:
> I don’t think you can call this a bug.
> 
> I think it's a bug, but reasonable people can disagree. An "unintentional difference in behavior" is another way to describe this report.

A difference in behavior is fair to point out, and I’d even agree people might assume all user agents will have the same HSTS behavior; but I think the best we can do is point out that HSTS is optional to implement; so if a user agent is missing this feature, that should be reported as a feature request, not as a bug.

If encrypted connections are important to you as a server operator, it seems the only foolproof way to avoid plaintext communication is don’t listen on port 80.

>  
> As far as I know, this behavior is not standardized as any part of HTTP, but is described and centrally managed by Chromium project. That is, it’s a feature of Google Chrome and nobody else is under any obligation to implement it.
> 
> HSTS is defined by RFC 6797. It's true that the preload list can vary between versions of browsers, but in this case I found that the macOS versions of browsers other than Safari had these TLDs preloaded, while the iOS versions of these browsers did not. I understand why this happened, but I think it would be a stretch to call it intentional. The discrepancy existed for over a year, and no browser vendor seemed aware of it.

The preload list isn’t a part of RFC 6797, which is itself optional to implement.

>  
> And even if it was, I don’t really see how you can say “At least 600k domains were impacted”. What would an attack look like? You have to have a user-agent willing to send a sensitive payload in plaintext, and a server with port 80 open to receive it.
> 
> 600k is a conservative estimate based on the number of domains that seemed to be registered under these TLDs. Any browser without these TLDs preloaded would first attempt to connect via HTTP if supplied with an http:// URL or a schemeless URL (like "foo.dev <http://foo.dev/>").  At that point, any server could provide a response. You might think "surely there will be a scary warning", but this actually was not the case in all browsers, especially on mobile phones. Safari did say "Not Secure" in the address bar, but other browsers just showed an "(i)" info icon instead of a lock, so a user would have to notice the absence of a lock.

Note that even TLS will indicate which domain you’re connecting to. If server operators make diligent use of HttpOnly and Secure for cookies, the only information at risk is the path component of the URI you’re connecting to, your user-agent details, and maybe a payload (if you can figure out a way to get an HTML form to POST to an http: endpoint without a warning).

But I agree I’d like to see better privacy designed into first-time connections. I know the HTTP WG is working on a new DNS record specifying connection requirements. Unfortunately it seems this new scheme would also be optional, and probably not widely implemented for some time.

Personally, I would like to see a new “web:” scheme that mandates usage of SRV, or the proposed HTTP service record, whatever it ends up being named… this new URI scheme would effectively require that clients understand the security requirements before connecting. People pointed out this would be a barrier to adoption; but for some applications, this is entirely the point.

Cheers,

Austin.


> 
> thanks,
> Rob
>