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

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Sep 2019 14:18:53 -0700

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.

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.

thanks,
Rob

[1]
https://www.ixiacom.com/company/blog/paypal-netflix-gmail-and-uber-users-among-targets-new-wave-dns-hijacking-attacks

[2] https://tools.ietf.org/html/rfc8164

---

From: David Benjamin <[email-masked]>
Date: Fri, 20 Sep 2019 17:41:17 -0400

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 <[email-masked]> 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
> 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/

> 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

> 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

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Sep 2019 14:56:11 -0700

> https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/

That is a little stronger than I thought it was, but nothing close to the
warnings one sees for certificate errors or SafeBrowsing warnings. I just
checked Firefox, Chrome, and Safari. Firefox used a little red. :)

The UI for insecure email in GMail is stronger. (totally-red lock)

> https://tools.ietf.org/html/rfc6797#section-12.3

They do--I've seen the static list built into Chrome. It seems like the
list should be global, because the lists didn't seem to match on some
important sites. Browsers did record the HSTS data after one visit, but
clearing browsing data seemed to reverse this in some cases.

Also, if we consider apps that do not present an address bar, an
OS-provided list would seem beneficial.

thanks,
Rob

---

From: Nick Harper <[email-masked]>
Date: Fri, 20 Sep 2019 15:35:39 -0700

> clearing browsing data seemed to reverse this in some cases.

As far as I know, every browser that ships an HSTS preload list bases it
off of the one maintained at hstspreload.org. Different browsers have
different criteria for what exactly to include and may revalidate that a
domain meets the requirements for inclusion (or meets additional
requirements than the Chromium requirements). The update cycle for
different browsers also impacts which version of the list is in use, but
ultimately I'd expect all browsers to have approximately the same list.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Sep 2019 15:41:59 -0700

On Fri, Sep 20, 2019 at 3:35 PM Nick Harper <[email-masked]> wrote:

> 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

---

From: Alexander Neilson <[email-masked]>
Date: Sat, 21 Sep 2019 11:18:58 +1200

> On 21/09/2019, at 10:44, Rob Sayre <[email-masked]> 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:
> 
> 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

---

From: Alexander Neilson <[email-masked]>
Date: Sat, 21 Sep 2019 09:43:26 +1200

On 21/09/2019, at 09:22, Rob Sayre <[email-masked]> 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.
> 
> 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] https://www.ixiacom.com/company/blog/paypal-netflix-gmail-and-uber-users-among-targets-new-wave-dns-hijacking-attacks
> 

Regards
Alexander

---

From: Rob Sayre <[email-masked]>
Date: Sat, 21 Sep 2019 13:29:06 -0700

On Fri, Sep 20, 2019 at 10:04 PM Alexander Neilson <[email-masked]>
wrote:

> 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?
>

Off-list, someone pointed out that this is pretty similar to the
already-proposed "Encrypt All Sites Eligible (EASE) Mode"
https://www.eff.org/deeplinks/2018/12/how-https-everywhere-keeps-protecting-users-increasingly-encrypted-web

It seems like some of the bigger sites that aren't on
https://hstspreload.org are probably having trouble with its
"includeSubDomains" requirement. I'd propose letting any site in the Alexa
Top 1000 (or some other traffic measurement) opt in without that
requirement. They can then add subdomains where it makes sense. Example:
https://hstspreload.org/?domain=mail.google.com.

It also seems like hstspreload.org should be part of OS networking stacks,
especially on mobile phones. I don't know whether any vendor has done this.

thanks,
Rob