Added post by Jeremy Rand "Meet DNSSEC-HSTS"

_posts/2018-11-05-dnssec-hsts.md

@@ -0,0 +1,26 @@
+---
+layout: post
+title: "Meet DNSSEC-HSTS: A Different Approach to Defeating TLS Stripping"
+author: Jeremy Rand
+tags: [News]
+---
+
+TLS stripping is an attack first popularized by Moxie Marlinspike.  The attack allows a MITM attack, even for websites that use TLS, by exploiting the fact that web browsers will usually default to using HTTP without TLS unless the user specifically typed the `https://` in the URL bar.  Since the initial connection doesn't use TLS, the attacker has full control over what the user receives, and therefore the attack can "strip" any HTTP-to-HTTPS redirect that the website tries to issue.
+
+There are several approaches to defeating TLS stripping.  HSTS can defeat TLS stripping by having the website return a "Strict Transport Security" (STS) HTTP header when the user connects to it over HTTPS.  This header indicates that, in the future, the web browser should always connect to that website with TLS.  HSTS works reasonably well, but it has two problems: it can be used as a "supercookie" (and therefore violates privacy), and it relies on the "TOFU" (Trust On First Use) security model (meaning that the first time you connect to a given website, HSTS doesn't protect you).  These two problems in combination lead to the unfortunate fact that HSTS offers almost no protection in Tor Browser, because Tor Browser wipes the HSTS state whenever you request a new identity.
+
+Other approaches are based on preload lists.  Google maintains a list of websites who have requested that their STS status be preloaded into the web browser; the Google preload list is used by both Chromium and Firefox (and probably other browsers as well).  The Google preload list doesn't rely on TOFU like HSTS does, but it doesn't scale well, and it's heavily centralized (you might not want Google to control whether your website is protected from TLS stripping).  Browser extensions like EFF's HTTPS Everywhere implement their own preload lists, which are similar to Google's preload list except that they're more decentralized (users can choose which extensions they trust to supply preload lists) and that they don't require websites to manually opt in.  Browser extensions don't scale much better than the Google preload list, and while they do offer trust agility, there's still trust involved.
+
+Another approach (implemented by the HTTPS Finder extension for Firefox) is to dynamically discover STS rules by trying to connect over HTTPS first, and if the connection succeeds, create an STS rule; otherwise (if no STS rule already exists) fall back to HTTP.  This scales very well, doesn't require any third party to maintain a preload list, and doesn't require any action by websites besides supporting HTTPS.  Unfortunately, it relies on TOFU, and it will usually break when it encounters a website that listens on HTTPS but redirects to HTTP.  (The NSA's website is probably the most famous, and most ironic, example of this, but it's a disturbingly common practice.)
+
+Still another approach is a scorched-earth approach: enforce TLS on *all* connections.  HTTPS Everywhere allows this as an optional configuration, and while it's clearly the most secure approach (no trusted third party, no TOFU, doesn't rely on websites to do anything special, and it scales excellently), it also impacts usability since it means you can't access sites that don't use TLS.
+
+I've been hacking around with yet another approach.  Let's assume (for the purpose of argument) that we trust the output of our DNS resolver.  If we can determine via DNS (somehow) that the website owner intended for TLS to be used, then we can consider that to be an STS rule.  It just so happens that there's an easy heuristic to determine this: if a `TLSA` record exists for `_443._tcp.example.com.`, then we can infer that there is a website at `https://example.com/`.  This isn't a theoretically perfect heuristic, since technically nothing stops a server from hosting two different websites over HTTP and HTTPS for the same hostname, and also technically nothing stops a server from using a protocol besides HTTPS on TCP port 443.  That said, in the real world, those edge cases are extremely rare, and there's not much legitimate reason for anyone to use such a setup.
+
+So, I've created a Firefox extension called DNSSEC-HSTS, which implements exactly that.  When you try to navigate to an HTTP website, DNSSEC-HSTS checks whether a `TLSA` record indicates that an HTTPS version is likely to be available, and if so, it upgrades the request to HTTPS before Firefox opens the connection.  Obviously, my primary interest here is in using this for Namecoin (since `TLSA` records are required for TLS on a `.bit` domain), but it works fine for arbitrary non-Namecoin domain names.
+
+Are there downsides to this approach?  Probably.  One downside that I can think of is that, since most web browsers don't validate certificates against `TLSA` records, DNSSEC-HSTS might incentivize websites to serve `TLSA` records without checking their correctness.  This doesn't bother me too much, since I'm primarily interested in Namecoin (where serving invalid `TLSA` records will get noticed, and fast).  A theoretically better approach would be to use a separate DNS record to indicate STS status, but that has the disadvantage of not protecting websites who don't explicitly add that new record.  Another downside is that you need to have a trustworthy DNS resolver, such as a locally installed DNSSEC-Trigger instance (which presumably is already true in the case of Namecoin, so I don't consider this to be a big problem).
+
+A release of DNSSEC-HSTS for Firefox should be coming fairly soon, and hopefully I'll be able to make it work properly in other browsers like Tor Browser and Chromium as well.
+
+This work was funded by NLnet Foundation's Internet Hardening Fund.