HSTS from Top to Bottom | Hacker News Reader

HSTS from Top to Bottom

troyhunt.com

51 pointsweinzierl33 comments

The article mentions preloading but doesn't go into detail.

You can apply for Chrome preload via https://hstspreload.org/ which I ends up in Chrome source, the list is then replicated to other browsers by their maintaniers.

HSTS Preload will prevent initial-access downgrade attacks for clients using versions of browsers with your domain as a HSTS preload. The downside is preload removal is difficult and would take a fair while to propogate.

Also another common misconception is disabling port 80 will remediate the issue - if an attacker can intercept and modify traffic they are able to open and redirect the port to a node under their control. https://letsencrypt.org/docs/allow-port-80/

From 2016:

"95% of HTTPS servers vulnerable to trivial MITM attacks"

https://news.netcraft.com/archives/2016/03/17/95-of-https-se...

HSTS making progress...

Still doesn't solve the first-request problem. When can we start using DNSSEC to help prevent DNS hijacking in the first place?

The preload option is supposed to solve the first-request problem

It's not feasible to use preload on a wide scale. Do you think that every secure site should have to be included in the source of your browser to have security?

For me deploying DNSSEC was as easy as clicking a button in Cloudflare DNS panel. Though I don't understand how DNSSEC is helping with HSTS? Is there some DNS record which is supposed to force browser to use HTTPS?

Technically DANE could be used for this today, but you’d have to get the web browser vendors aboard in order to implement it, and I’m afraid that it might go over about as well as support for SRV records.

Probably never. DNSSEC has been in the works for over 20 years, and has practically no real-world deployment.

Even without DNS hijacking, a MITM (such as a router) could still intercept your password.

Isn't DNSSEC supposed to prevent you from connecting to the wrong origin, presumably avoiding an unencrypted connection? A router can't intercept anything on an encrypted connection.

DNSSEC ensures a hostname resolves to the right IP address. But when you make a TCP connection to that IP address, a MITM can listen in on (and modify) that TCP connection.

Another problem is I believe DNSSEC is only validated by the recursive resolver. So if the end user is using an external recursive resolver (e.g. 8.8.8.8) then the data between the user and the recursive resolver can still be spoofed by a MITM, and also the recursive resolver itself could behave maliciously.

DNSSSEC can distribute an actual certificate pin (DANE), making the web PKI semi-obsolete, distribute a CA pin (CAA), or any other PKI data should the clients support it.

I think most people agree that the domain is the trust point nowadays (as most certificates are domain validated; there is a whole industry pushing organization name validation with EV, but it has never worked well in the real world), so it makes sense to anchor the http certificate to the domain one.

DANE hasn't really taken off much outside mail traffic (where it is optional but to some extent forced when present). The jury is still out on CAA. As for the rest, one can only hope for new initiatives. The open web PKI only works for the big actors.

Does DNSSEC upgrade http:// to https:// ? If not, then it doesn't solve the specific problem Troy and I were talking about (namely MITMs snooping on http:// traffic).

What's the primary attack that DANE attempts to protect against? CAs issuing certs to entities they shouldn't? Troy doesn't seem to be worried about those attacks.

There are several kinds of MITM. DNSSEC makes rebinding, poisoning and DNS interception for capturing and modifying traffic neutered. Being a protocol it is however ineffective against other attacks such as unauthorized domain transfers.

What artursapek describes is probably that, while you are of course correct that no improved encryption could possibly improve on the fact that web browsers still default to unencrypted communications.

So the problems are mostly complementary, but rebinding and poisoning offers an attacker more ways of intercepting cleartext traffic unless mitigated.

The major mail providers are busy killing off DNSSEC for SMTP as well; see SMTP-STS, which has as an explicit goal defeating downgrade attacks without resorting to DNSSEC.

> > A router can't intercept anything on an encrypted connection.

> MITM can listen in on (and modify) that TCP connection.

Not if the connection is encrypted, as was stipulated.

> Another problem is I believe DNSSEC is only validated by the recursive resolver.

True, you need a trusted connection to the resolver you use (which you also have to trust). Therefore, you can either use DoT or DoH to some resolver which you have to trust, or run your own local resolver on the local machine.

>Not if the connection is encrypted, as was stipulated.

Hmm, yes, there does appear to be some confusion. I misread artursapek and missed the "encrypted connection" part.

Assuming "encrypted connection" refers to the connection to the website, then my question is what is telling the connection to be encrypted? The article is about current non-encrypted connections. So something needs to be done to convert those http:// connections into https:// connections, and I don't think DNSSEC does that.

> So something needs to be done to convert those http:// connections into https:// connections, and I don't think DNSSEC does that.

HSTS is already being used for this, although it uses a TOFU-like model where the very first connection is vulnerable to MITM downgrade. DANE (which uses DNSSEC) does not have this problem, and could be used for this, but it’s the browser vendors who would have to be convinced to implement it, and I don’t have high hopes.

DANE does in practice have this problem; see the chain-extension fiasco. A lot of these things look like they work until you actually try to get a browser to do them.

I can’t seem to find what you are referring to. Could you specify what the problem is?

From memory, but you can just look it up:

DANE is untenable in browsers because (1) it's much too slow and (2) a lot of networks won't pass DANE lookups; if your HTTPS connection relies on DNSSEC/DANE "just working", the web breaks for those people.

So instead, you staple DANE records to the TLS handshake with an extension.

But that's incoherent: the purpose of DANE is to establish a root of trust for TLS connections, but the extensions carried in a TLS handshake depend on a root of trust. In practice, if you can get an X.509 certificate issued, you can strip stapled DANE records. So there's no point to stapling DANE records.

Solution: dynamic pinning and continuity over multiple connections.

> DANE is untenable in browsers because

Neither of those things make sense to me:

> (1) it's much too slow

Browsers already do A/AAAA DNS lookups, which presumably does not present any huge latency issue. If latency would be a problem, DNS servers could send the additional DANE records in the “additional” section, just like they do now with an A or AAAA query leading to a CNAME record; this would completely eliminate any additional latency with DANE.

> and (2) a lot of networks won't pass DANE lookups

I don’t think so; if that were the case, DANE would not be rolled out as widely as it is for SMTP.

I'm not making either of those up; you can find them at the top of the chain-extensions draft, which is a collaboration between Mozilla and DNSSEC people. Both are also in Adam Langley's "Why Not DANE In Browsers" post. I'm pretty confident these are real issues, and not really a productive live debate for HN.

You’re merely making an argument from authority, not responding to anything I wrote.

Furthermore, that blog post is both old (and itself refers to even older references to back up its claims, and has a large discussion of now-fixed issues in DNSSEC) and it also presents an incomplete list of reasons for why DANE might be wanted. It is ignoring DANE’s HTST-like feature of signalling that HTTPS must be used, to prevent protocol downgrade attacks, which is exactly the reason we are discussing DANE here.

I can no longer keep track of what you're trying to argue. The chain-extensions debacle is less than a year old. It was motivated by the same concerns as the AGL article. Since you acknowledged upthread not being aware of chain-extensions in the first place, despite it being a big-ticket issue for DANE deployment (enough for Geoff Huston to write a whole article bemoaning its failure as a standard) I'm not sure from where you're drawing the certitude that these issues aren't real.

And now you’re arguing Ad hominem in addition to argument from authority, and still not actually responding. I think we’re done here.

Do i remember correctly that Chrome wanted to deprecate HSTS about a year ago?

What happened with that?

You're thinking of HPKP

https://raymii.org/s/blog/Chrome_68_is_deprecating_HPKP.html

Which is a shame really. I understand why they're doing it, it's stressful as hell to configure, since if you do it really wrong you might as well just write off your domain name, but the extra assurance was nice.

Not only it is stressful to configure, it can be used to hold your domain at ransom.

IMO browsers should just use TLSA records instead. They already starting to use DoH, so DNS is secure even without DNSSEC.

It's less bad, but far from secure seeing it is not end-to-end encrypted.

A simple solution is just to forbid http altogether. No properly encrypted HTTPS connection - no website, sorry (unless you downloaded some kind of firefox developer build). But we're not there yet.

Reply on news.ycombinator.com