4 ms·

I think the whole design of PKI is bad. Instead on trusting a handful CAs that have to charge for or severely limit access to their signing servers, PKI could b

I think the whole design of PKI is bad. Instead on trusting a handful CAs that have to charge for or severely limit access to their signing servers, PKI could be based on the DNS hierarchy. CA type certificates do have an extension for specifying at which DNS level and below they are valid, so the root DNS operators would have the root cert and would only issue signatures for CA certs to TLDs that are limited to those TLDs only. A TLD administrator would then sign CA certs for second level domains that are time limited to domain validity and have their CA limited to this SLD and below. An owner of an SLD would automatically get a CA cert and wouldn't need to depend on third party issuers (and their OCSP servers to which data leaks), complicated ACME protocols, ... A bank in question could then sign certs for each user and point domains user58284u2874localhost.bank.example to 127.0.0.1. Even better, the bank would be much more secure because there would be no other CA that could sign certs for it's domain, apart from THE SINGLE root CA and it's TLD CA. This entire process of basing on DNS as a security chain already exists in form of DANE/TLSA, which is IMO an even simpler protocol than CA and cert chains. With DANE, TLSA records containing TLS public keys (or cert hashes), trusted on a specific domain, are published in DNS zones, which must be signed by DNSSEC. That way, TLS certificates don't even need to be signed by a CA. No browser currently implements DANE however, it's major users are currently mailservers.

ilyt 4y ago
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.
- hoppla 4y ago
  Do you know of any CAs that are willing to issue such certificates?
  - michaelt 4y ago
    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.
  - ilyt 4y ago
    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
- aaomidi 4y ago
  You can already do this by effectively getting a pool of wildcard certs.
  - wolrah 4y ago
    >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.
    - egberts1 4y ago
      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-x509v3-extensions.html 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).
8organicbits 4y ago
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 https://m.youtube.com/watch?v=UawS3_iuHoA
nine_k 4y ago
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.
- deleted 4y ago
  [deleted]
- tptacek 4y ago
  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.
- jesprenj 4y ago
  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.
toast0 4y ago
> 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.
tptacek 4y ago
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.
- topranks 4y ago
  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.

ilyt 4y ago

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.

hoppla 4y ago
Do you know of any CAs that are willing to issue such certificates?
- michaelt 4y ago
  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.
- ilyt 4y ago
  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
aaomidi 4y ago
You can already do this by effectively getting a pool of wildcard certs.
- wolrah 4y ago
  >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.
  - egberts1 4y ago
    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-x509v3-extensions.html 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).

8organicbits 4y ago

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 https://m.youtube.com/watch?v=UawS3_iuHoA

nine_k 4y ago

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.

deleted 4y ago
[deleted]
tptacek 4y ago
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.
jesprenj 4y ago
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.

toast0 4y ago

> 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.

tptacek 4y ago

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.

topranks 4y ago
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.