Preferences

I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously.

You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. You then use that specific control to get a CA to forge a certificate for you (and if the CA is capable of using any information to detect that this might be a forgery, the attack breaks).

And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking--impersonating somebody to the nameserver and getting the account switched over to them.


> I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously.

You claim it is fine-tuned, but it has happened in the real world. It is actually even better for attackers that it is "obscure", because that means it is harder to detect.

> but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about.

Yes, all layers of the stack need to be secure. I am not making assumptions about the other layers - this thread is about DNS.

> if the CA is capable of using any information to detect that this might be a forgery

They are not. The only mitigation is "multi-perspective validation", which only addresses a subset of this attack.

> And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking

Yes, because other kinds of DNS hijacking are solved by HTTPS TLS. If TLS and CAs are broken, nothing is secure.

> You claim it is fine-tuned, but it has happened in the real world.

Sure, but it seems like his comment is still responsive; if DNSSEC is deployed, they perform a BGP hijack & can impersonate everyone, and they just impersonate the server after the DNS step?

If that's the threat model you want to mitigate, it seems like DNSSEC won't address it.

> and they just impersonate the server after the DNS step?

Yes, there are different mitigations to prevent BGP hijacking the webserver itself. Preventing a rogue TLS certificate from being issued is the most important factor. CAA DNS records can help a bit with this. DNS itself however is easiest solved by DNSSEC.

There are a lot of mitigations to prevent BGP hijacks that I won't get too much into. None are 100%, but they are good enough to ensure multi-perspective validation refuses to issue a TLS certificate. The problem is that if those same mitigations are not deployed on your DNS servers (or you outsource DNS and they have not deployed these mitigations) it is a weak link.

I don't see you responding to the question. You're fixating on protections for DNS servers, because that is the only circumstance in which DNSSEC could matter for these threat actors, not because they can't target the address space of the TLS servers themselves (they can), but because if you concede that they can do this, DNSSEC doesn't do anything anymore; attackers will just leave DNS records intact, and intercept the "authentic" server IPs.

So far your response to this has been "attackers can't do this to Cloudflare". I mean, stipulated? Good note? Now, can you draw the rest of the owl?

I am focusing on DNS because this thread is about DNSSEC. The topic of doing it in to the TLS servers themselves is a tangent not relevant to this thread.
> You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about.

An attacker impersonating a DNS server still won't be able to forge the DNSSEC signatures.

No, they can't. Why would they bother? They'll just impersonate the IP the CA uses for the ALPN challenge.
Well, this won't work with DNSSEC. It's a good argument for it.
An attack against BGP where the attacker takes over traffic for an IP address isn't at all prevented by DNSSEC.

The sequence there is:

1. I hijack traffic destined for an IP address

2. Anything whose DNS resolves to that IP, regardless of whether or not they use DNSSEC, starts coming to me

In this model, I don't bother trying to hijack the IP of a DNS server: that's a pain because with multi-perspective validation, I plausibly have to hijack a bunch of different IPs in a bunch of different spots. So instead I just hijack the IP of the service I want to get a malicious cert for, and serve up responses to let me pass the ALPN ACME challenge.

Sure. But you won't have a TLS certificate for that address, if the host uses a DNS-based ACME challenge and prohibits the plain HTTP challenge: https://letsencrypt.org/docs/caa/

So DNSSEC still offers protection here.

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal