Re: Fetching http:// URIs over TLS by default
David Benjamin <davidben@chromium.org> Fri, 20 September 2019 21:43 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 D3E71120913 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 20 Sep 2019 14:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=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 yLyw-8e_jZ7H for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 20 Sep 2019 14:43:51 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 B7F96120905 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 20 Sep 2019 14:43:51 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iBQfA-0002sm-E2 for ietf-http-wg-dist@listhub.w3.org; Fri, 20 Sep 2019 21:42:00 +0000
Resent-Date: Fri, 20 Sep 2019 21:42:00 +0000
Resent-Message-Id: <E1iBQfA-0002sm-E2@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <davidben@google.com>) id 1iBQf7-0002rz-2E for ietf-http-wg@listhub.w3.org; Fri, 20 Sep 2019 21:41:57 +0000
Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <davidben@google.com>) id 1iBQf5-0000cN-Ap for ietf-http-wg@w3.org; Fri, 20 Sep 2019 21:41:56 +0000
Received: by mail-pf1-x443.google.com with SMTP id 205so5395991pfw.2 for <ietf-http-wg@w3.org>; Fri, 20 Sep 2019 14:41:34 -0700 (PDT)
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=EF1H2bcDO6nzOW4Phib199c/xafiUDI6PAZ4y9OdwK4=; b=ZoOmTsBg8mB0Q37t81OGaWCwmJwjkl4mrfY8P3ra39Ew8aEq/dgF4gqM0JTIuVkdK2 8oc7ZcLFDSL9PZy0rhS9rkH71F7AfqWpqaLt9mIKh57jGKZ2CFvGjjDDnzveh+7Db1J+ fRwQkzlP2zTV4mFNEefWAm2o4EJX4hDyMR8m0=
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=EF1H2bcDO6nzOW4Phib199c/xafiUDI6PAZ4y9OdwK4=; b=Y7P7gXPgyJ+vSyvOnRxU3P8XKsbb0Dh9PwiG/ET2OCBTlkdutnGsXuZqsmRAA2514w SDxtX1dg3UcXUr7J1XJgxNhY8yxNaIT27jPUTSuqerW8Wvr7P0AOjrP1YWgdeYVJ8S6v wQ9JbuLQg2Ht0GJRhwCd52T03c3dNfwNM9QlFvkcVGlhHaCJO9Vnu5hIoC73RXRHqqtg 6n0/aMjEleSP9fxcor4tKk5VOm0n24JBjCTUXEVDSZBjJ10GcPxZrgb+Ws+i6g+R9Aum 1Gaq21LQ0hWtjLzoVAWwlENIHL31eZIkypKeDSciJ2bdSK3m5PH7u3gEzxZUlSwNLKVn M3Rg==
X-Gm-Message-State: APjAAAXVlH9LUPcClUlFQIxyQtSFyL+CoMOQwts49JL673iIGf4duV7W qgcNtaCnIoisyQsUTjutbIjxb++rJcH5q0Tw1lYY
X-Google-Smtp-Source: APXvYqyBc7CC1pJl3Vlm5JTBJsJDL1eA8L5mI7OanWI62s/7rvWMvn7+eylUqBBPwIVUX4lwwjEBlRfTYtJgeXitwAc=
X-Received: by 2002:a62:524a:: with SMTP id g71mr19795006pfb.154.1569015693737; Fri, 20 Sep 2019 14:41:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6Sxd8p3tOGBVFvrpnj3cUD23quvQHnwbz0RPoF+=13VhUw@mail.gmail.com>
In-Reply-To: <CAChr6Sxd8p3tOGBVFvrpnj3cUD23quvQHnwbz0RPoF+=13VhUw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 20 Sep 2019 17:41:17 -0400
Message-ID: <CAF8qwaCTzoBofvQLWw=uQkbNEEFpTsz45Hv4k53NpLiTZavVEg@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000001323c9059302ef83"
Received-SPF: pass client-ip=2607:f8b0:4864:20::443; envelope-from=davidben@google.com; helo=mail-pf1-x443.google.com
X-W3C-Hub-Spam-Status: No, score=-11.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iBQf5-0000cN-Ap f6856e621ff97e556604e0e2f07fa996
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Fetching http:// URIs over TLS by default
Archived-At: <https://www.w3.org/mid/CAF8qwaCTzoBofvQLWw=uQkbNEEFpTsz45Hv4k53NpLiTZavVEg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37026
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>
Assuming I've read this right, I have good news for you! Both of your ideas below have already been implemented and shipped. On Fri, Sep 20, 2019 at 5:22 PM Rob Sayre <sayrer@gmail.com> wrote: > Hi all, > > I was looking at the behavior of several popular websites in the context > of HSTS and DNS hijacking[1]. It seems like these attacks rely on the > relatively-benign security UI of clear-text HTTP pages, the fact that > browsers will send HTTP traffic in the absence of HSTS information, and the > fact that several popular sites still serve redirects to TLS URIs over port > 80. That last part is particularly problematic, because a rogue DNS server > can point at an address that will serve a malicious 200 response, and > rewrite links on the served page. (I found several banks serving redirects > from port 80...) > > I read the "opportunistic encryption" RFC[2], but the proposal in the > subject line seems different. I had two ideas: > > 1) Start marking any domain that is one label + a tld as insecure if > served over http. So, "foo.co.jp" would be marked as insecure over http, > but "foo.bar.co.jp" would not. Obviously, this could be ratcheted up over > time. > URLs served over http are marked insecure these days, regardless of how many labels there are: https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/ > 2) Allow domains to opt-in to HSTS out-of-band, like in software updates > for an OS. This idea seems intriguing, because it would seem to improve > security as participants join, unlike a TLS trusted-root store. > The HSTS spec suggests doing this as a the pre-load list and indeed browsers ship just that. https://tools.ietf.org/html/rfc6797#section-12.3 https://hstspreload.org > Of course, other approaches, like DoH/DoT and DNSSEC, would attack this > problem from a different angle. Also, I'm not sure if this group is the > right place to propose this idea. > The HTTPSSVC record proposal includes a DNS-triggered http to https upgrade, which sounds like what you're thinking there. (This one is not yet implemented anywhere, to my knowledge.) https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03#section-4.2
- Fetching http:// URIs over TLS by default Rob Sayre
- Re: Fetching http:// URIs over TLS by default David Benjamin
- Re: Fetching http:// URIs over TLS by default Rob Sayre
- Re: Fetching http:// URIs over TLS by default Nick Harper
- Re: Fetching http:// URIs over TLS by default Rob Sayre
- Re: Fetching http:// URIs over TLS by default Alexander Neilson
- Re: Fetching http:// URIs over TLS by default Alexander Neilson
- Re: Fetching http:// URIs over TLS by default Rob Sayre