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

Alexander Neilson <> Sat, 21 September 2019 05:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CBB912004F for <>; Fri, 20 Sep 2019 22:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
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: (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FXXUU4ZBh8_Y for <>; Fri, 20 Sep 2019 22:03:59 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id DF062120052 for <>; Fri, 20 Sep 2019 22:03:58 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1iBXWs-0000NI-5R for; Sat, 21 Sep 2019 05:01:54 +0000
Resent-Date: Sat, 21 Sep 2019 05:01:54 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1iBXWg-0000LX-Pk for; Sat, 21 Sep 2019 05:01:42 +0000
Received: from www-data by with local (Exim 4.89) (envelope-from <>) id 1iBXWg-0003Xs-5n for; Sat, 21 Sep 2019 05:01:42 +0000
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1iBQh1-0002x3-0H for; Fri, 20 Sep 2019 21:43:55 +0000
Received: from ([2607:f8b0:4864:20::441]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1iBQgy-0000du-Lt for; Fri, 20 Sep 2019 21:43:54 +0000
Received: by with SMTP id x127so5373993pfb.7 for <>; Fri, 20 Sep 2019 14:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:date:subject:message-id :references:in-reply-to:to; bh=c7fl8CjF7FeKdnT0w9mm4G7GyiF3wI8gySFl7hz1mjc=; b=KKpMg+7s+u2iV/ZyNV92fAMeTudRzD69ijDqi9z2ydNuQx0mNd6nRMdnGlj97qu+5j CC52THuwTcCPpWKLtJtyBIlgdqcvWbzDpe9/l+K+fRDDmAg7jstqsgV7x6q973XroXSt lOVBfko3JUnJ523yEsZcnFvocC+7xS+UDZA/T4QcNhKa5a1JAXIBwwkCV+4zH37eppAc 5/2KPXkVnUNpvveol1t5Ckx7Qr7FgZCrXdiSvEHGXdMg4EcmBKDrVtBbZqS+2m+seRH8 fC8J4AZ/4zsCymTgVXS10pg40yHPyu3Ax1dzzipcKOTixN9cGaXbf7OZNhfq634GBHyZ 5FEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:references:in-reply-to:to; bh=c7fl8CjF7FeKdnT0w9mm4G7GyiF3wI8gySFl7hz1mjc=; b=fmXqpLM3kIeZYM4CYrj4HTZV0dAQrpDA5CSaxj7wTxxwl7wjORG5d/Epurja+O0dzK pyMIKRccsQMR3YX2PxWdILAyJh8ChT2EvHr/3CURWPIelHgxDTSCnLayqjce8ytv9xfQ lnN7OH4Ft/iKP0M1IIP0cVRJoxF4dbvTYkopPja/stVUnV+Y4TQXMVD8yWCrSgpBfcBT jSy1w/szpDBx8kl/GKoyDTxGeZ78puxClbIx+gZgEpCU4sVkAgmbbk0DmkVZFuWB6JtR 222v170olctADgQGnxahlNFEvCKwmP3gs0biSjVAmRk7J5Gma9wwNaOsb9rDseXAYZ2p exzQ==
X-Gm-Message-State: APjAAAVLtHlzLvcg3NF86sHzFPRgQStlQ2Dea7FzGlq6wsNnWt2DjpgD JmtmaS0wpeYmcgHaYGsZmaFJ/iQsDd5g0w==
X-Google-Smtp-Source: APXvYqxoqec5CLNDwU4v6gPBygMiIYRW9X7DiAheTyjn3/c3EmgSnSIw0eDfJI4slntBDfD7OoJXrg==
X-Received: by 2002:aa7:8813:: with SMTP id c19mr17288397pfo.101.1569015809970; Fri, 20 Sep 2019 14:43:29 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id w5sm3322268pfn.96.2019. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2019 14:43:28 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-ACC5514C-F7A4-4FCD-8E95-EDECA58EC1CD
Content-Transfer-Encoding: 7bit
From: Alexander Neilson <>
Mime-Version: 1.0 (1.0)
Date: Sat, 21 Sep 2019 09:43:26 +1200
Message-Id: <>
References: <>
In-Reply-To: <>
X-Mailer: iPhone Mail (17A5844a)
Received-SPF: pass client-ip=2607:f8b0:4864:20::441;;
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: 1iBQgy-0000du-Lt e4b53a8fe59648313af88aa01607f3fd
X-caa-id: 579148088c
Subject: Re: Fetching http:// URIs over TLS by default
Archived-At: <>
X-Mailing-List: <> archive/latest/37031
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 21/09/2019, at 09:22, Rob Sayre <> 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, "" would be marked as insecure over http, but "" would not. Obviously, this could be ratcheted up over time.
> 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.
> 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.

Thinking out loud here. 

With web browsers already “hiding” the protocol in most situations now I wondered if a more effective move would be to encourage default behaviours for web clients to try HTTPS first. 

Kind of like the happy eyeballs approach to IPv6 where try V6 first and try the v4 connection a short while later and take the first response outcome. (Again this can be stepped up over time pushing more towards secure)

I’m sure there will be some breakage (servers that respond on 443 with bad Certs or without the real site) but with the “not secure” flags posting around browsers and the like this should be a decreasing population. 

Also this could be bypassed if the user provided an explicit protocol typed into the address bar. 

Many web browsers already seem to be doing your (1) but for most domains on HTTP. I always tend to lean towards helping the end user get the “best” outcome (for measures of “best”) without them all having to understand and also automatic improvement for the web. 

> thanks,
> Rob
> [1]
> [2]