- From: Alexander Neilson <alexander@neilson.net.nz>
- Date: Sat, 21 Sep 2019 09:43:26 +1200
- To: ietf-http-wg@w3.org
- Message-Id: <9F47B6A3-601A-42CC-ADCC-AE71B07A097A@neilson.net.nz>
On 21/09/2019, at 09:22, 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. > > 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 > > [2] https://tools.ietf.org/html/rfc8164 Regards Alexander
Received on Saturday, 21 September 2019 05:01:42 UTC