5 ms·

Don't you think that it would be better if certificate authorities were limited to certain TLDs? For example, a company from country A limited to A's national T

Don't you think that it would be better if certificate authorities were limited to certain TLDs? For example, a company from country A limited to A's national TLD? This way even if they are ordered to produce a fake certificate, they can only decrypt traffic for country A's sites. Also browsers should display a warning when a certificate issuer for a website changes.

XorNot 4y ago
What I don't get is how this wasn't thought up to be put into the SSL/TLS standard when it was built. How did we wind up with infinitely powered root certification authorities?
- dikei 4y ago
  The current PKI is geared toward ease-of-use and adoption. It can also be turned completely around: only trust a single root certificate. This design is often used in client authentication: each client need to get its certificate signed by the one single CA that's trusted by the server.
  - XorNot 4y ago
    Right but implementation wise we've never implemented as a default anything else. Domain suffix pinning is available as an extension, but that's all it is - very few TLS stacks support it and that's unlikely to ever change.
- moring 4y ago
  Is this actually part of the standard? AFAIK TLS allows/demands to authenticate one or both sides via certificates, and defines a mechanism to delegate trust via certificate chains. It does not, AFAIK, define how trust is established, and my guess is that the standard authors realized that this is an infinitely complex topic that should not be intermixed with the technical and cryptographic side of the problem. It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user.
  - 9034725985 4y ago
    > It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user. This flexibility is what allowed let’s encrypt to bootstrap, right?
  - bawolff 4y ago
    nameConstraints x509 extension is part of a different standard - https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10 https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
  - tialaramex 4y ago
    TLS itself has no opinion about how certificates work. AFAIK it would be totally fine by the standard to put a JPEG photo of a your primary school certificate for 10m swimming where certificate goes in the protocol. If the other party is OK with your proof that you can swim to secure the connection, all is good. Netscape invented all this stuff in the 1990s as SSL. Turns out you need a PKI to make it work, because of a tricky edge case which otherwise makes the whole thing worthless. So, they used the existing but little used X.509 PKI left over from the X.500 directory work, even though the Internet is not part of the envisioned global network X.500 is for. The X.509 PKI had a bunch of famous brand "trustworthy" companies minting certificates. PKIX, an IETF working group to figure out how to force X.509 to be suitable for the Internet, adds stuff like SANs (Subject Alternative Names, a way to express Internet ideas about naming like IP addresses and DNS names) but that all happens after SSL 2.0 and SSL 3.0 and people start writing https URLs.
- mschuster91 4y ago
  The same reason that lies behind many problems in IT: a lot of the early (and now still foundational) protocols date back to times where the participants in the network were universities or other large entities (governments, large corporations) and trust was assumed between them. Obviously, that broke down over time, and nefarious actors (both governmental and private) popped up.
  - moring 4y ago
    That isn't the only reason. Another big one is that the problem itself is hard, so noone could come up with an easy solution. How would you establish trust in a world without root CAs? Peer-to-peer? That would require you to constantly monitor the activity of those peers and update your lust of trusted certificates. Singular trusted entities like browser or OS vendors? We already have that. Browser/OS certificate list are currently the entry point and have even higher priority than root CAs -- that is what the article is about. Government bodies are an easy-to-go "trusted" entity because, while you may or may not actually trust them, you are forced to "trust" them in many aspects of daily life anyway. You are forced to rely on the fact that the police doesn't randomly knock on your door and arrest you. Governmnent bodies may (depending on your country) simply demand higher taxes than you owe them, and you have to fight a lawsuit to avert that. Government bodies can easily falsify evidence that makes you lose your house because it now says that somebody else is the owner (lawsuit again).
    - mschuster91 4y ago
      I outlined parts of the problem in another comment in this thread: https://news.ycombinator.com/item?id=33814801 https://news.ycombinator.com/item?id=33814801 Basically, establishing trust in a matter of "I am actually talking to the legitimate server behind example.com and not a MITM" is easy, that could be solved by DNSSEC and cert pinning (although for legacy reasons, we went with CAs as the middle man). But the really interesting thing, which is unsolved to date, is making sure that when you type "bank.com" in a browser, you have some sign that you are actually talking to Bank LLC and not some other entity. In ye olde times, you didn't have to worry about someone else spoofing the domain name of "bank.com", e.g. as "b4nk.com" or "bänk.com", for one because access to registering domains was complex and expensive, and for one because criminals hadn't found out they could make money...
- mananaysiempre 4y ago
  There is the part where the usage of X.509 certificates for DNS names on the Internet, as opposed to in the context of the (nonexistent) X.500 directory, is a gigantic hack[1]. This means the definition of “when it was built” is rather hazy. Also, the 1994 Netscape implementation literally accepted a CN=foo.com certificate when connecting to bar.org, so the state of SSL when it was built is not exactly a stellar reference. Still, the name constraints extension, which restricts all certificates (transitively) issued from a given CA to a given DNS subtree, has been in the “Internet profile” of X.509 (PKIX) since the December 1996 draft[2]. The problem from this technical point of view is that very few implementations supported it until a couple of years ago[3]. [1] https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b4f https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b... [2] https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-part1-03#section-4.2.1.11 https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-p... [3] https://bettertls.com/ https://bettertls.com/
zinekeller 4y ago
> Don't you think that it would be better if certificate authorities were limited to certain TLDs? For example, a company from country A limited to A's national TLD? This way even if they are ordered to produce a fake certificate, they can only decrypt traffic for country A's sites. I think it would harm users relying on certain sites. This already happened with CNNIC and .cn, so I don't think that mandatory restrictions would make it better (and besides, the only CAs which voluntarily ask to restrict issuance to certain TLDs are government CAs).
- netheril96 4y ago
  > I think it would harm users relying on certain sites. This already happened with CNNIC and .cn Care to elaborate? I don't really understand how it harms users.
  - ProtoAES256 4y ago
    CNNIC was caught signing fake Google certs.
  - zinekeller 4y ago
    In 2015, CNNIC have impersonated Google's domains (which while Google have a minimal presence in China is still a faux pas). Also to clarify: restricting it to specific TLDs where the CA physically operated would amplify local laws, while restricting it to TLDs that are outside the CA's physical presence would basically mess up enforcement and would spur governments to curate a mandatory sanctioned list (heard of EU QWAC?) It's a lose-lose case either way.
    - netheril96 4y ago
      I’m aware of the incident, but I don’t understand your reasoning. Had CNNIC been restricted to issue certificates only for .cn domains, the incident would have never been possible. That should be a supporting evidence for CA name constraints. I don’t understand the “amplifying local law” part. How is restricting the power amplifying?
hn_go_brrrrr 4y ago
Some CAs are limited in the way you describe. For instance, this just came up a few days ago: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/DotaWOS0v1E https://groups.google.com/a/mozilla.org/g/dev-security-polic...
AndyMcConachie 4y ago
This is partly the idea behind DANE. With a DNS TLSA record one can create limits like this on a domain name.
Puts 4y ago
I think that a good system would be that the key can be signed by multiple parties. For example if you are running a web shop, your certificate could be signed by Visa if you accept card payments, by your registrar to prove that you own the domain, by the tax office in your country to prove that you are a real company and so on. And then the browser would show these signatures as badges when clicking/hovering the padlock icon. So essentially the more signatures the more trustworthy.
- mananaysiempre 4y ago
  Right now, CAs in the Web PKI certify authenticity, not trustworthiness: when the system works correctly, a successful TLS handshake with satan.com tells you that you have connected to the actual satan.com and perhaps that it is operated by Satan, Inc (although it’s still on you to check whether it’s the Delaware one or the Kentucky one[1]). It does not, and is not supposed to, tell you whether it’s smart to sell your soul there, CA marketing materials (“users trust sites that ...”) notwithstanding. What you are proposing is an attempt at solving an entirely different problem that is, furthermore, largely orthogonal to ensuring the integrity and confidentiality of Internet traffic. It would be nice if that problem were solvable, but every time the Web PKI flirted with that it ended horribly[2]. (And now the EU authorities are trying to force it anyway, it seems[3].) Ensuring your bytes end up on the host you named, intact and unsnooped, is a comparatively easy problem that’s also pretty meaningful, and it seems smart to restrict ourselves to that. (I’d have advocated for DNSSEC+DANE instead of CAs, even, if I had any confidence at all in the DNS registrars’ ability to handle key material and willingness to give up domain control when that ability fails.) [1] https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ https://arstechnica.com/information-technology/2017/12/nope-... [2] https://www.usenix.org/system/files/sec19-thompson.pdf https://www.usenix.org/system/files/sec19-thompson.pdf [3] https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck-qwacs-like-a-duck-probably-an-ev-certifiacate/ https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
  - bandrami 4y ago
    Unfortunately TLS is already conflating two problems as it is: 1. Is the opposite party who they claim to be? 2. Did a third party alter or eavesdrop on the transmission? That is, am I simply being phished in private or is the government also listening to me being phished? It's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever and we delayed secure transport by decades by tying it to the generally less-useful question in #1. There are few entities online I trust more than I would trust someone impersonating them: basically only if money is changing hands. But I don't need to know that e.g. ycombinator.com is actually ycombinator.com because I don't trust ycmonbinator.com any more than I would trust someone impersonating ycombinator.com.
denton-scratch 4y ago
> For example, a company from country A limited to A's national TLD? That's not an example of limiting CAs to certain TLDs; that's an example of limiting certificate users to a single CA. I'd sooner use a self-signed certificate than one signed by a monopoly government-controlled CA.
xorcist 4y ago
It is obvious that inventing the CA business was a mistake, in retrospect. Netscape wanted nothing to do with it in practice. What we should do is to delegate the few CAs that legitimately do non-domain validated certicates for specialized applications to only this. That includes things like signed code. Things like extended validation was invented solely to print more money and should be phased out of web browsers. They are not "more secure" and should not be regarded as such in any user interface. The parties to issue domain validated certificates should be the domain registries. They do their job reasonably well already. They are already tasked with issuing domain ownership. It is only natural that they should validate this ownership cryptographically as well. It is a trivial extension to their business, and the registry/registrar model can be kept intact. The trust chain for a domain validated certificate today includes both the registry and the CA, and either can fail. The risk is strictly minimized by removing the CA from the equation. CAs provide no value to the end user. You will find several high profile people arguing against this. Do note that every one has vested interest in the status quo, either directly or indirectly by having CAs and governmental agencies as their clients. How do we change this system? Mozilla has by way of their history some weight in these matters, and several capable people on board. It is my intense hope that they have a long term plan. Let's Encrypt is, as great an achievement as it is, still built on a broken trust model. But it could also be an excellent beachhead into a strictly better trust model for the end users.
- newaccount74 4y ago
  > Things like extended validation was invented solely to print more money and should be phased out of web browsers. They are not "more secure" and should not be regarded as such in any user interface. I think it would be great if something like EV certificates were available from national governments. We have pretty solid digital ID support in Austria, but all the tech for signing and authenticating documents (useful for invoices or account statements) require special software, and aren't built into web browsers and email clients that people use. It would be nice if I clicked a link in an invoice email, if I could check that aws-billing.at is indeed a domain that belongs to "Amazon Web Services" registered in Austria or if it is a phishing attempt from a script kiddie in a foreign country.
Crosseye_Jack 4y ago
But it could backfire in the other direction. Lets say I trust AWS and Let's Encrypt (the two CA's I currently use for my domains - that was the only reason I picked those two, both HQ'ed in the US), would I then be forced to used a Spanish CA for my .es domains or a Tuvaluan CA for my .tv domains?

XorNot 4y ago

What I don't get is how this wasn't thought up to be put into the SSL/TLS standard when it was built. How did we wind up with infinitely powered root certification authorities?

dikei 4y ago
The current PKI is geared toward ease-of-use and adoption. It can also be turned completely around: only trust a single root certificate. This design is often used in client authentication: each client need to get its certificate signed by the one single CA that's trusted by the server.
- XorNot 4y ago
  Right but implementation wise we've never implemented as a default anything else. Domain suffix pinning is available as an extension, but that's all it is - very few TLS stacks support it and that's unlikely to ever change.
moring 4y ago
Is this actually part of the standard? AFAIK TLS allows/demands to authenticate one or both sides via certificates, and defines a mechanism to delegate trust via certificate chains. It does not, AFAIK, define how trust is established, and my guess is that the standard authors realized that this is an infinitely complex topic that should not be intermixed with the technical and cryptographic side of the problem. It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user.
- 9034725985 4y ago
  > It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user. This flexibility is what allowed let’s encrypt to bootstrap, right?
- bawolff 4y ago
  nameConstraints x509 extension is part of a different standard - https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10 https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
- tialaramex 4y ago
  TLS itself has no opinion about how certificates work. AFAIK it would be totally fine by the standard to put a JPEG photo of a your primary school certificate for 10m swimming where certificate goes in the protocol. If the other party is OK with your proof that you can swim to secure the connection, all is good. Netscape invented all this stuff in the 1990s as SSL. Turns out you need a PKI to make it work, because of a tricky edge case which otherwise makes the whole thing worthless. So, they used the existing but little used X.509 PKI left over from the X.500 directory work, even though the Internet is not part of the envisioned global network X.500 is for. The X.509 PKI had a bunch of famous brand "trustworthy" companies minting certificates. PKIX, an IETF working group to figure out how to force X.509 to be suitable for the Internet, adds stuff like SANs (Subject Alternative Names, a way to express Internet ideas about naming like IP addresses and DNS names) but that all happens after SSL 2.0 and SSL 3.0 and people start writing https URLs.
mschuster91 4y ago
The same reason that lies behind many problems in IT: a lot of the early (and now still foundational) protocols date back to times where the participants in the network were universities or other large entities (governments, large corporations) and trust was assumed between them. Obviously, that broke down over time, and nefarious actors (both governmental and private) popped up.
- moring 4y ago
  That isn't the only reason. Another big one is that the problem itself is hard, so noone could come up with an easy solution. How would you establish trust in a world without root CAs? Peer-to-peer? That would require you to constantly monitor the activity of those peers and update your lust of trusted certificates. Singular trusted entities like browser or OS vendors? We already have that. Browser/OS certificate list are currently the entry point and have even higher priority than root CAs -- that is what the article is about. Government bodies are an easy-to-go "trusted" entity because, while you may or may not actually trust them, you are forced to "trust" them in many aspects of daily life anyway. You are forced to rely on the fact that the police doesn't randomly knock on your door and arrest you. Governmnent bodies may (depending on your country) simply demand higher taxes than you owe them, and you have to fight a lawsuit to avert that. Government bodies can easily falsify evidence that makes you lose your house because it now says that somebody else is the owner (lawsuit again).
  - mschuster91 4y ago
    I outlined parts of the problem in another comment in this thread: https://news.ycombinator.com/item?id=33814801 https://news.ycombinator.com/item?id=33814801 Basically, establishing trust in a matter of "I am actually talking to the legitimate server behind example.com and not a MITM" is easy, that could be solved by DNSSEC and cert pinning (although for legacy reasons, we went with CAs as the middle man). But the really interesting thing, which is unsolved to date, is making sure that when you type "bank.com" in a browser, you have some sign that you are actually talking to Bank LLC and not some other entity. In ye olde times, you didn't have to worry about someone else spoofing the domain name of "bank.com", e.g. as "b4nk.com" or "bänk.com", for one because access to registering domains was complex and expensive, and for one because criminals hadn't found out they could make money...
mananaysiempre 4y ago
There is the part where the usage of X.509 certificates for DNS names on the Internet, as opposed to in the context of the (nonexistent) X.500 directory, is a gigantic hack[1]. This means the definition of “when it was built” is rather hazy. Also, the 1994 Netscape implementation literally accepted a CN=foo.com certificate when connecting to bar.org, so the state of SSL when it was built is not exactly a stellar reference. Still, the name constraints extension, which restricts all certificates (transitively) issued from a given CA to a given DNS subtree, has been in the “Internet profile” of X.509 (PKIX) since the December 1996 draft[2]. The problem from this technical point of view is that very few implementations supported it until a couple of years ago[3]. [1] https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b4f https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b... [2] https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-part1-03#section-4.2.1.11 https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-p... [3] https://bettertls.com/ https://bettertls.com/

zinekeller 4y ago

> Don't you think that it would be better if certificate authorities were limited to certain TLDs? For example, a company from country A limited to A's national TLD? This way even if they are ordered to produce a fake certificate, they can only decrypt traffic for country A's sites. I think it would harm users relying on certain sites. This already happened with CNNIC and .cn, so I don't think that mandatory restrictions would make it better (and besides, the only CAs which voluntarily ask to restrict issuance to certain TLDs are government CAs).

netheril96 4y ago
> I think it would harm users relying on certain sites. This already happened with CNNIC and .cn Care to elaborate? I don't really understand how it harms users.
- ProtoAES256 4y ago
  CNNIC was caught signing fake Google certs.
- zinekeller 4y ago
  In 2015, CNNIC have impersonated Google's domains (which while Google have a minimal presence in China is still a faux pas). Also to clarify: restricting it to specific TLDs where the CA physically operated would amplify local laws, while restricting it to TLDs that are outside the CA's physical presence would basically mess up enforcement and would spur governments to curate a mandatory sanctioned list (heard of EU QWAC?) It's a lose-lose case either way.
  - netheril96 4y ago
    I’m aware of the incident, but I don’t understand your reasoning. Had CNNIC been restricted to issue certificates only for .cn domains, the incident would have never been possible. That should be a supporting evidence for CA name constraints. I don’t understand the “amplifying local law” part. How is restricting the power amplifying?

hn_go_brrrrr 4y ago

Some CAs are limited in the way you describe. For instance, this just came up a few days ago: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/DotaWOS0v1E https://groups.google.com/a/mozilla.org/g/dev-security-polic...

AndyMcConachie 4y ago

This is partly the idea behind DANE. With a DNS TLSA record one can create limits like this on a domain name.

Puts 4y ago

I think that a good system would be that the key can be signed by multiple parties. For example if you are running a web shop, your certificate could be signed by Visa if you accept card payments, by your registrar to prove that you own the domain, by the tax office in your country to prove that you are a real company and so on. And then the browser would show these signatures as badges when clicking/hovering the padlock icon. So essentially the more signatures the more trustworthy.

mananaysiempre 4y ago
Right now, CAs in the Web PKI certify authenticity, not trustworthiness: when the system works correctly, a successful TLS handshake with satan.com tells you that you have connected to the actual satan.com and perhaps that it is operated by Satan, Inc (although it’s still on you to check whether it’s the Delaware one or the Kentucky one[1]). It does not, and is not supposed to, tell you whether it’s smart to sell your soul there, CA marketing materials (“users trust sites that ...”) notwithstanding. What you are proposing is an attempt at solving an entirely different problem that is, furthermore, largely orthogonal to ensuring the integrity and confidentiality of Internet traffic. It would be nice if that problem were solvable, but every time the Web PKI flirted with that it ended horribly[2]. (And now the EU authorities are trying to force it anyway, it seems[3].) Ensuring your bytes end up on the host you named, intact and unsnooped, is a comparatively easy problem that’s also pretty meaningful, and it seems smart to restrict ourselves to that. (I’d have advocated for DNSSEC+DANE instead of CAs, even, if I had any confidence at all in the DNS registrars’ ability to handle key material and willingness to give up domain control when that ability fails.) [1] https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ https://arstechnica.com/information-technology/2017/12/nope-... [2] https://www.usenix.org/system/files/sec19-thompson.pdf https://www.usenix.org/system/files/sec19-thompson.pdf [3] https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck-qwacs-like-a-duck-probably-an-ev-certifiacate/ https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
- bandrami 4y ago
  Unfortunately TLS is already conflating two problems as it is: 1. Is the opposite party who they claim to be? 2. Did a third party alter or eavesdrop on the transmission? That is, am I simply being phished in private or is the government also listening to me being phished? It's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever and we delayed secure transport by decades by tying it to the generally less-useful question in #1. There are few entities online I trust more than I would trust someone impersonating them: basically only if money is changing hands. But I don't need to know that e.g. ycombinator.com is actually ycombinator.com because I don't trust ycmonbinator.com any more than I would trust someone impersonating ycombinator.com.

denton-scratch 4y ago

> For example, a company from country A limited to A's national TLD? That's not an example of limiting CAs to certain TLDs; that's an example of limiting certificate users to a single CA. I'd sooner use a self-signed certificate than one signed by a monopoly government-controlled CA.

xorcist 4y ago

It is obvious that inventing the CA business was a mistake, in retrospect. Netscape wanted nothing to do with it in practice. What we should do is to delegate the few CAs that legitimately do non-domain validated certicates for specialized applications to only this. That includes things like signed code. Things like extended validation was invented solely to print more money and should be phased out of web browsers. They are not "more secure" and should not be regarded as such in any user interface. The parties to issue domain validated certificates should be the domain registries. They do their job reasonably well already. They are already tasked with issuing domain ownership. It is only natural that they should validate this ownership cryptographically as well. It is a trivial extension to their business, and the registry/registrar model can be kept intact. The trust chain for a domain validated certificate today includes both the registry and the CA, and either can fail. The risk is strictly minimized by removing the CA from the equation. CAs provide no value to the end user. You will find several high profile people arguing against this. Do note that every one has vested interest in the status quo, either directly or indirectly by having CAs and governmental agencies as their clients. How do we change this system? Mozilla has by way of their history some weight in these matters, and several capable people on board. It is my intense hope that they have a long term plan. Let's Encrypt is, as great an achievement as it is, still built on a broken trust model. But it could also be an excellent beachhead into a strictly better trust model for the end users.

newaccount74 4y ago
> Things like extended validation was invented solely to print more money and should be phased out of web browsers. They are not "more secure" and should not be regarded as such in any user interface. I think it would be great if something like EV certificates were available from national governments. We have pretty solid digital ID support in Austria, but all the tech for signing and authenticating documents (useful for invoices or account statements) require special software, and aren't built into web browsers and email clients that people use. It would be nice if I clicked a link in an invoice email, if I could check that aws-billing.at is indeed a domain that belongs to "Amazon Web Services" registered in Austria or if it is a phishing attempt from a script kiddie in a foreign country.

Crosseye_Jack 4y ago

But it could backfire in the other direction. Lets say I trust AWS and Let's Encrypt (the two CA's I currently use for my domains - that was the only reason I picked those two, both HQ'ed in the US), would I then be forced to used a Spanish CA for my .es domains or a Tuvaluan CA for my .tv domains?