Re: Fetching http:// URIs over TLS by default

Alexander Neilson <alexander@neilson.net.nz> Sat, 21 September 2019 05:04 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 D92D8120072 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 20 Sep 2019 22:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=neilson.net.nz
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 F9Ie1uoZ5YAO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 20 Sep 2019 22:03:59 -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 D6ED712004F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 20 Sep 2019 22:03:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iBXWk-0000Mp-KI for ietf-http-wg-dist@listhub.w3.org; Sat, 21 Sep 2019 05:01:46 +0000
Resent-Date: Sat, 21 Sep 2019 05:01:46 +0000
Resent-Message-Id: <E1iBXWk-0000Mp-KI@frink.w3.org>
Received: from uranus.w3.org ([128.30.52.58]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <alexander@neilson.net.nz>) id 1iBXWg-0000LY-P5 for ietf-http-wg@listhub.w3.org; Sat, 21 Sep 2019 05:01:42 +0000
Received: from www-data by uranus.w3.org with local (Exim 4.89) (envelope-from <alexander@neilson.net.nz>) id 1iBXWg-0003Xu-9T for ietf-http-wg@listhub.w3.org; Sat, 21 Sep 2019 05:01:42 +0000
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 <alexander@neilson.net.nz>) id 1iBSBU-0004OV-Kc for ietf-http-wg@listhub.w3.org; Fri, 20 Sep 2019 23:19:28 +0000
Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <alexander@neilson.net.nz>) id 1iBSBR-0002Rq-5E for ietf-http-wg@w3.org; Fri, 20 Sep 2019 23:19:28 +0000
Received: by mail-pg1-x529.google.com with SMTP id s1so3558696pgv.8 for <ietf-http-wg@w3.org>; Fri, 20 Sep 2019 16:19:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neilson.net.nz; s=google; h=content-transfer-encoding:from:mime-version:date:subject:message-id :references:in-reply-to:to; bh=aJbjq5fHgnGkFvrgVbTbn1PPNMor6rVBT0Kp3ri1nM0=; b=p3slaWHmLftxH3eE/eU+WUm8UgYlaVvmsDlfUPqDfWHUcpxAMlxwu7o6qIt46gzVnh hJTcAS1efgyxAUmHi5hNQAcPw26Xw/2ABBGWX8DIr7JTCLe9YX8lJwqcNKRJt6UONaHO R9IQHV3TztrYw7hCSQ5bIz96DJ5AnkxeW7S870Zo5ALVTAgOlvhOaKcPLL6zmIOk5ayF stsp2pkdG2FKi6jcTpBYTNx80rrb5atZjzTzkVZEW9CbhKCmPIWqrQFqlqYOOO0xIZpP wS17Fm1xGXM9GIOsHZ1rMH9vCthqhD7StQ2cA+eOiTnQRwkQPTj1octMjLg8+WGg2UQq jEYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:references:in-reply-to:to; bh=aJbjq5fHgnGkFvrgVbTbn1PPNMor6rVBT0Kp3ri1nM0=; b=EbpUMl7et48pfCgdKgY9RZv5bUCj5SDkccSMnAPEMkHGmlixdKOxFgAP4IDSTi3rvn rM7LzDBRasJguWZDLylRUf4RKy28u6cNXqBTiuuotmp1WYSpPtaK1bUaxzuoZSsy7Wrj 5sTd9LtaOIVTzdwysmTkNaufffpYgaF/p7egmpbm8Tnr/Qljf8yeqxzGs/TDOaE5M6yi D10GrIDYk39wG1LDFMjtmBxUgK6GecstZneuglUA3dnKjUKHLy4Fq73xNaaG4uSVt6uC ullRB/M5G9Pcwbl+5tEor8sDG2TmIkVc/+hlrMSCAuwIR0hRc4GQsNWpqQiMOJXhwQqA YlAg==
X-Gm-Message-State: APjAAAVsqPvmTtXqF2A1wbgrbxEAhu7j9xuCvWFUNCev11w0LCHRaWZ7 4MOZhsWcc9KA+16CA3HrdU8MGre23y9biA==
X-Google-Smtp-Source: APXvYqx3tjjMoIJyxtXiMCNFudGyCMqW9FjWfxCxOytiRvlx+r+aRRHZnkA2mB7CkMgUZK6KinuwVw==
X-Received: by 2002:a65:590a:: with SMTP id f10mr18207292pgu.37.1569021542198; Fri, 20 Sep 2019 16:19:02 -0700 (PDT)
Received: from [192.168.26.210] (125-236-242-113.adsl.xtra.co.nz. [125.236.242.113]) by smtp.gmail.com with ESMTPSA id p189sm4442193pfp.163.2019.09.20.16.18.59 for <ietf-http-wg@w3.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2019 16:19:01 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-AF37EEC4-D92C-43AE-8207-002B2C203C1B"
Content-Transfer-Encoding: 7bit
From: Alexander Neilson <alexander@neilson.net.nz>
Mime-Version: 1.0 (1.0)
Date: Sat, 21 Sep 2019 11:18:58 +1200
Message-Id: <2368E30A-5A95-4B0D-9ACC-1E9EF194FF66@neilson.net.nz>
References: <CAChr6SyeTKGc2HDsKjAGwtOVjgDZRrhuxqQTfnZ0m2wsvWMwEg@mail.gmail.com>
In-Reply-To: <CAChr6SyeTKGc2HDsKjAGwtOVjgDZRrhuxqQTfnZ0m2wsvWMwEg@mail.gmail.com>
To: ietf-http-wg@w3.org
X-Mailer: iPhone Mail (17A5844a)
Received-SPF: pass client-ip=2607:f8b0:4864:20::529; envelope-from=alexander@neilson.net.nz; helo=mail-pg1-x529.google.com
X-W3C-Hub-Spam-Status: No, score=-4.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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iBSBR-0002Rq-5E 64764d0c8e2e6ebe72782eec8750e1c5
X-caa-id: 2eaac201cb
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Fetching http:// URIs over TLS by default
Archived-At: <https://www.w3.org/mid/2368E30A-5A95-4B0D-9ACC-1E9EF194FF66@neilson.net.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37030
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 21/09/2019, at 10:44, Rob Sayre <sayrer@gmail.com> wrote:
> 
> 
>> On Fri, Sep 20, 2019 at 3:35 PM Nick Harper <nharper@google.com> wrote:
> 
>> As far as I know, every browser that ships an HSTS preload list bases it off of the one maintained at hstspreload.org. 
> 
> I've found a bunch of small differences, but I agree that those aren't that important. I am looking at sites like these:
> 
> https://hstspreload.org/?domain=apple.com
> 
> https://hstspreload.org/?domain=google.com 
> 
> https://hstspreload.org/?domain=mozilla.org
> 
> These sites can include sign-in UI, and may not include any sensible "not secure" warning, depending on the browser and device form factor.
> 
> thanks,
> Rob

Going a little back to your original proposal (as clarified) do I understand correctly that you are suggesting that a specification be created stating that (in the first stage) any Domain of <name>.<TLD> served over HTTP is regarded as the equivalent of a certificate failure and should come with the full scale “this website may be trying to steal your information ...” style blocking page requiring a click onto “advanced” mode and bypassing or white listing?

If this is your proposal I feel the first step here would be to push towards https being the default whenever not specified (or even better trying for an “HTTPS Happy Eyeballs” where when not specified clients will try https first and http second after a short delay)

I don’t like the idea that users would have to remember to specify HTTPS every time when the work browsers have done has moved towards hiding the protocol from them more and more. Let’s use the end users lack of specificity to actively attempt to upgrade this (I believe there may have been an add on that did this in some browsers before) rather than beating them with a stick when they just type in google.com or <newswebsite>.<TLD> and clients go assume the “bad” choice and we them hit them with a blocking page. That risks training users more and more that those alerts should just be bypassed. 

Regards
Alexander