Hacker News Reader

A DNS PKI would also be controlled by a handful of unaccountable companies (you can't generally get signed name directly off the root), with the fun additional wrinkle of the most important of those companies being de jure controlled by state actors. It's hard to think of a worse option than DANE.

What's more, browsers have no real influence with DNS registries. They can kill misbehaving CAs, and have done so, to some of the largest CAs. But they can't kill a DNS registry; they can't even move their own names off a registry they don't trust (customers are going to keep hitting Google.com no matter what Google says).

That's important because browser influence over CAs has drastically modernized the WebPKI, most notably by creating an append-only cryptographic ledger (CT) that tracks every certificate issuance. That system doesn't exist for DANE and will never exist for DANE, because the browser vendors can't force the issue.

That's not why browsers don't use DANE; they don't use DANE because it doesn't work (for instance: large numbers of middleboxes won't pass DANE queries). But it's the reason nobody should support DANE.

You don't have to like the WebPKI or support it (I respect it more than I like it). By all means propose alternatives. Just don't make those alternatives a DNS PKI.

I think the central thing here is you need to trust the DNS anyway. If you control a domains DNS records you can get a Cert issued for that name under the existing WebPKI.

Given that scenario the current CA setup just adds many more entities that need to be trusted on top of that.

> (you can't generally get signed name directly off the root)

Yea you can (unfortunately IMO.) Just stump up the money. Most people have no need for that though.

> browsers have no real influence with DNS registries.

I’m not sure why the browser vendors being in control of this is so much better than ICANN. Google has undue influence here IMO.

> They can kill misbehaving CAs, and have done so, to some of the largest CAs. But they can't kill a DNS registry;

I think the difference is that the DNS hierarchy means only one set of published records exist for a domain. It’s not like the Web PKI where other certs can be issued I parallel by other CAs.

> they can't even move their own names off a registry they don't trust (customers are going to keep hitting Google.com no matter what Google says).

I’m not that familiar with all the processes here, but this seems like an abuse of a registrars power. Surely the gtld servers can stop delegating zones to bad actors? Have there been historical examples of something like google getting hijacked by their DNS registrar?

> append-only cryptographic ledger (CT) that tracks every certificate issuance. That system doesn't exist for DANE

As conflicting records can’t exist it’s trivial for an entity to monitor the published records for their domain, and alert on changes.

> it doesn't work (for instance: large numbers of middleboxes won't pass DANE queries).

That is true for many things. I don’t find it a good argument against protocols themselves.

No.

What is needed is less centralization, not more. I'll take the US society as an example: having congress, senate, president, courts, military, police, states, free press (with multiple participants), university etc means that to compromise democracy, you need to subvert many elements simultaneously.

Likewise, having DNS and PKI separate is a plus, as the cert is linked to DNS and finding a web server is done through DNS. To completely fool an attentive user, you would need to both fool their DNS and their pool of trusted certificate (or a single CA).

To increase security, we need more cross-linked layers that each require the other. We need to have more steps and more elements that a crooked player needs to control simultaneously in order to achieve an exploit.

For example, we could require multiple certs, so that you'd need to compromise multiple CA. Although, if you can add one CA to the trusted pool, then you can add 3, so this does not protect against actors that have access to the user's OS. But, on that front, if you got root access to a user's OS, you can do anything. Once you MITM them, you can make a user divulge their credentials. Only a physical fob with its own certs, DNS resolver and hardware-level private key can protect against that.

> What is needed is less centralization, not more.

I don't think depending on more CAs counts as constructive decentralization. Since every CA is ultimately trusted, the security of our PKI depends on the weakest link in the chain. A single exploited CA is enough to completely invalidate PKI security, whereas separating CAs based on DNS hierarchy means that a compromised CA for .SI would only affect domains under .SI.

> To completely fool an attentive user, you would need to both fool their DNS and their pool of trusted certificate (or a single CA).

Currently, due to the way domain ownership is verified, a compromised TLD registry leads not only to DNS compromise, but to TLS compromise as well, since domain ownership is verified via DNS by currently trusted CAs (most notably letsencrypt).

> We need to have more steps

Less steps that form a reliable security chain that can be easily monitored is IMO better for securing infrastructure than having to trust each and every obscure CA.

> we could require multiple certs

But this would significantly increase deployment complexity. And the domain registry can still lie about domain ownership so it still must be ultimately trusted.

Every CA isn't equivalently trusted.

One thing that tends to happen in these discussions is that people start with a set of axioms based on the circa-2002 era WebPKI, and just build an argument from first principles. That doesn't work. There has been a sea change since then in how browser root programs are managed.

Can't agree more. We got to a point where state actors control the public names that we use to refer to locations on the Internet. That's fine, and the logical conclusion of divvying up natural monopolies. When you have a namespace, someone needs to be the central authority for it. On a global system, you need to at least have as many namespaces as countries (plus whatever extra corporate fiefdoms you want to spin up, which I assume was what gTLDs were trying to do).

Ensuring you are communicating with the resource that you intended is a feature that does not need to be centralised, so it shouldn't be. Requiring a random third party on top of your central entity seemed like a bad idea when DANE was proposed, as CAs seemed like a rent-seeking middleman that offered nothing. In fact, it's actually a feature as you said. Because there are multiple, free and crucially, interchangeable third parties that can do this, the browsers are free to kick any misbehaving party out AND keep raising the bar of admission, like imposing CT requirements.

Right now, I don't have to place any trust on the state entity behind the hypothetical .xy domain when talking to a .xy website. They can return whatever DNS records they want to any user at any time, but assuming a TLS connection on top of WebPKI, they cannot silently perform a MitM on their own – while they have the power to fool a CA to give them a domain-validated certificate for any domain they control, doing that would be visible in CT logs for that well-behaved CA, meaning they would get caught. The incentive to do that is much less than if you were both the source of truth for the name system and the PKI infrastructure.

I've found Moxie Marlinspike's talk [1] to be a great overview of these sorts of issues. IIRC, he built an alternate system discussed in the talk. But I believe that's defunct. (Tangent, anyone know the postmortem on that?)

https://m.youtube.com/watch?v=UawS3_iuHoA

IIRC you can actually create CA/sub-CA that had permission only to given subdomains it's just that client support for that was very spotty.

It really is how it should be; get the CA for your domain and manage away, no reliance on 3rd party CA for each issue for certs on your domains.

Do you know of any CAs that are willing to issue such certificates?

The feature is called 'RFC 5280 Name Constraints' and nobody will issue you such certificates.

This is because some clients don't support the constraints, so if they give you a CA certificate that can sign any subdomain of evil.com you could use it to sign MITM certificates for good.com and, although you wouldn't fool modern web browsers, you might fool smart fridges and ancient android phones.

You can, however, use it to constrain your in-house corporate CA if you like.

Well our private one does lmao. Not useful in the slightest because of lack of client support.

We had an idea that our dev machines could live under *.dev.example.com and just have sub-ca generating certs for it and so any vulnerability or misgenerated cert would be limited to that environment, but lack of client support means that wouldn't work very well

You can already do this by effectively getting a pool of wildcard certs.

>You can already do this by effectively getting a pool of wildcard certs.

That is absolutely not "effectively" the same.

If I had a constrained CA cert for my domain, that CA cert would be the high value target which could potentially compromise my entire domain, but I could keep it as secure as I wanted to while issuing certificates for my world-facing machines specific to their own names.

Wildcard certs instead force me to put the high value cert on the world-facing machine. Suddenly every one of my web servers has the ability to impersonate my entire domain, and if compromised the attacker then has the keys to the kingdom.

Wildcard certs are a sorry excuse for a constrained CA cert, and the fact that we're stuck using them is terrible.

The only case where I consider wildcard certs acceptable is on a frontend machine that serves an entire dedicated domain, for example one of my systems has a lot of customername.domain.com and that particular domain is only used for that system, so everything under that domain would be those machines exclusively, making wildcard certs no additional risk.

If your domain use allows a wildcard-equipped web server to impersonate anything unrelated, it's probably a bad idea.

I do not know why this parent got voted down, but I do echo the parent’s sentiment that wildcard on the public-facing TLS/SSL servers still remains a weak point of security (from the server-side security POV).

Purpose of reducing wildcard usage in Subject Name (SAN) to within just the network portion that you control entirely still remains a valid security posture.

There are many types of TLS/SSL servers that can fork off of a public-facing wildcard FQDN; the thing is that ANY other CA (other than ones who signed wildcard CA) can be used to hang off a subdomain portion while its parent domain got differently issued by this wildcard-permitting CA.

The many types of CA end-nodes that can be created (unbeknownst to holder of this wildcard certificate holder) and used as subdomain servers are but not limited to:

1. Non-Leaf Intermediary CA

2. Cross-Certificate CA

3. TLE-Signing CA

4. Email Protection CA

5. Code Signing CA

6. Timestamping Intermediate CA

7. Identity CA

8. TLS Server Certificate

9. TLS Client Certificate

10. OSCP Responder Certificate

11. CRL Certificate

12. Code Signing Certificate

13. Email Protection Certificate

14. Timestamoing Certificate

15. Encryption Certificate

16. OSCP Responder Certificate

This above remains true even if DNSSEC setup is perfectly sound for you still have web (and OS) security to contend with; you also have to contend with correct OpenSSL settings for this wildcard CA sertificate (setting details. in link below).

Details on what OpenSSL settings for above are given in this:

https://egbert.net/blog/articles/which-certificate-uses-what...

(Note: my website shall be accessible only by non-Chrome web browsers, it is not accessible to Chrome-based clients due to its hardcoded client-side HTTP/2 mandate ignoring and overriding my TLS server’s must have HTTP/1.2-only, ChaCha-only. Chrome is broke, remains my assertion).

> (Note: my website shall be accessible only by non-Chrome web browsers, it is not accessible to Chrome-based clients due to its hardcoded client-side HTTP/2 mandate ignoring and overriding my TLS server’s must have HTTP/1.2-only, ChaCha-only. Chrome is broke, remains my assertion).

I guess everyone needs a hobby lmao. Also what is exactly the problem ? On wireshark I see chrome sending hello with TLS1.2/1.3 and TLS_CHACHA20_POLY1305_SHA256 (0x1303) then getting rejected https://imgur.com/a/HjZormT

Correct. TLSv1.2 is getting obsoleted due to several CVEs, so block that.

I would be talking about my server mandating HTTP/1.3 over Chrome mandating HTTP/2.0 of which Chrome does poorly in concise error messaging. Since my server decides, it fails.

On an unrelated note, stick with TLS v1.3 whenever you can.

I suggest you fix the HTTP TLS-less version of the site, so that chromium browsers may access the plaintext version.

Currently I get a 404 Not Found for the linked HTML file when connecting via plaintext.

TLS only complicated things (: I don't really need to verify the website integrity and privacy when reading an article from a HN commenter I do not know (: Maybe it's only about cosmetics -- a green padlock is more pleasing than a red triangle.

Ah, then you are asking me to reveal my website to Chrome-based users and to support users who like running vulnerabilites. ‘K, no thanks.

> PKI could be based on the DNS hierarchy.

With domain control certificates it basically is. If you control the domain name, you're getting a cert. Sure, there's an intermediary, and yeah they can sign bad certs; but... Now the certificate transparency is mandatory, bad issuances end up recorded and that will lead to CAs getting cancelled.

Does this offer a single CA per TLD? Or a single mandated CA per whatever DNS subtree?

This makes such a CA a SPOF, and juicy target for attacks or governmental coercion. Delisting it for bad practices, even if thee practices are well-known becomes infeasible.

If you are perplexed by choice, enjoy the fact that the choice exists.

It's not so much a juicy target for governmental coercion as it is an active arm of governmental authority, as you've seen every time DOJ has taken down a site and replaced it with their goofy logo.

If a government agency takes over a domain name, which they can, they can just as well obtain a TLS cert from LetsEncrypt.

DNS registries are already SPOF.