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

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