Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS-Persist-01: A New Model for DNS-Based Challenge Validation

letsencrypt.org

Post reply on HN
Print view View original

91–100 of 164 posts

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#91

Post by IgorPartola »

mcpherrinm wrote: post #85
IgorPartola wrote: post #81

Earlier quoted context omitted.

That’s fair but I also have to trust every provider between my DNS server and LE’s servers to not intercept DNS responses. Since DNS isn’t encrypted anyone anywhere between them can modify the traffic and get a certificate if I understand correctly.

Two current mitigations and one future: DNSSEC prevents any modification of records, but isn’t widely deployed. We query authoritative nameservers directly from at least four places, over a diverse set of network connections, from multiple parts of the world. This (called MPIC) makes interception more difficult. We are also working on DNS over secure transports to authoritative nameservers, for cases where DNSSEC isn…

Ah that makes sense. I was wondering why I haven’t heard of cases of successfully attacks like this. Thank you for the info!

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#92

Post by UltraSane »

Ayesh wrote: post #16

I'm surprised the ballot passed, unanimously even! I get that storing the DNS credentials in the certificate renewal pipeline is risky, but many DNS providers have granular API access controls, so it is already possible to limit the surface area in case the keys get leaked. Plus, you can revoke the keys easily. The ACME account credentials are also accessible by the same renewal pipelines that has the DNS API credent…

I use AWS Route53 and you can get incredibly granular with API permissions

Key condition keys for this purpose include:

    route53:ChangeResourceRecordSetsActions: Limits actions to CREATE, UPDATE, or DELETE.

    route53:ChangeResourceRecordSetsRecordTypes: Limits actions to specific DNS record types (e.g., A, CNAME, TXT).

    route53:ChangeResourceRecordSetsRecordValues: Limits actions based on the specific value of the DNS record.

    route53:ChangeResourceRecordSetsResourceRecords: For more complex scenarios, this can be used to control access based on the full record set details.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#94

Post by msmith »

IgorPartola wrote: post #72

Am I just stupidly missing something or does this in theory allow anyone who controls a DNS server for my domain or anyone who controls traffic between LE and the DNS server for my domain to get a TLS certificate they can use to impersonate my domain? I suppose the same is true for DNS-01 but this would make it even easier because the attacker can just put up their LE account instead of mine into the DNS response and…

To mitigate the threat from an attacker who controls the network between the cert issuer and the DNS server, CAs will check the DNS records from multiple vantage points.

Let's Encrypt has been doing this for several years, and it's a requirement for all CAs as of 2024.

[1] https://cabforum.org/2024/08/05/ballot-sc067v3-require-domai...

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#95

Post by dboreham »

nfredericks wrote: post #67
amluto wrote: post #65

Earlier quoted context omitted.

Name one that doesn’t have an AWS-style per-query cost. (There might well be a nice one, but I haven’t found it yet.)

Might be obvious, but Cloudflare

Cloudflare DNS isn't fully functional (at least for me). Can't be used for general purpose DNS hosting imho.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#98

Post by xyzzy_plugh »

tialaramex wrote: post #80
inahga wrote: post #62

Earlier quoted context omitted.

You should persist certs somewhere. Otherwise your availability is heavily tied to LE’s uptime.

Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.

Now you depend on CT log providers uptime, which as far as I can tell is worse than LE.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#99

Post by gerdesj »

My LE experience (post HTTP-01 and now DNS-01) - its a bit of a palava. I don't have to open port 80 which is nice for ... security audits but gains zero security benefit.

I have a PowerDNS server running locally with a static IPv4 address via NAT and I have created a DNS domain and enabled dynamic DNS updates from certain IPv4 addresses with a pre-shared key.

For each cert you need a DNS CNAME pointing to my DNS domain in a specific format. Then we have to get to grips with software to do the deed. acme.sh is superb for !Windows. simple-acme is fine for Windows. I still setup each one by hand instead of ansible/Zenworks/whatever because I'm a sucker for punishment and still small enough for now.

DNS-Persist-01 is not something I think I will ever need but clearly someone does.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#100

Post by cyberax »

tptacek wrote: post #84
cyberax wrote: post #71

Earlier quoted context omitted.

Yes, and it'd be great if DNSSEC added an "advisory" signature level. So it can be deployed without doing a leap of faith. But let's not pretend that WebPKI is perfect. More than one large service failed at some point because of a forgotten TLS certificate renewal. And more than one service was pwned because a signing key leaked. Or a wildcard certificate turned out to be more wildcard than expected. I understand the…

I don't really understand most of this comment but you opened up this subthread with "Come on. It's not dangerous", and, as you're acknowledging here, it clearly is quite dangerous.

DNSSEC is not dangerous. Pretty much the worst thing is breakage, not an accidental compromise.

It's also more secure, compared to ACME. An on-path attacker can impersonate the site operator and get credentials. DNSSEC is immune to that.

Post reply on HN