4 ms·

The CA system is so broken. Even if you pick a trustworthy CA, you're at the mercy of the weakest link (any random other CA elsewhere in the world). I feel we

by 0x0 10y ago

The CA system is so broken. Even if you pick a trustworthy CA, you're at the mercy of the weakest link (any random other CA elsewhere in the world). I feel we would be better off if CA tasks were limited to the registrar responsible for any given domain. For non-EV certificates, this removes the need for fragile ownership checks. Also, a technical measure could probably be put in place on clients so other registrars/CA can't spring fake certificates on your domain, by cross-checking that the CA is also the actual registrar. This would stop the race-to-the-bottom for both registrars and CAs, since if you pick a highly trustworthy CA you could be more confident no other CA would be able to wrongly issue a certificate for your domain (edit: or that your own CA would betray you). If you want top notch security, you could pay a premium, but actually get value for your dollars by picking a "more secure" registrar-and-CA service - instead of today's wildly varying prices for non-EV certificates, where expensive CAs bring zero value for their premium.

TheDong 10y ago
A minimal first step would be to split CAs out into "per-tld" CAs. It would be a relatively easy change for browsers and ssl libraries to switch to saying "these Chinese authorities are only valid for .cn domains", or "these government CAs are only valid for .gov domains". That wouldn't be as good as something closer to what you suggest, but it would be a lot easier to implement and would help a decent bit. There are of course CAs that would remain global, and this wouldn't help if that's the large majority (Verisign, Digitrust, Comodo would be the obvious global ones)... but I believe there's a super longtail of CAs that honestly shouldn't be able to issue for most country TLDs.
- alcari 10y ago
  I wish we lived in a world where X.509 name constraints[0] were actually useful, but unfortunately we don't, and I think getting browsers (never mind other TLS clients) to enforce them is even less likely than the various root stores revoking known-bad CAs. [0]: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10
  - wiml 10y ago
    We're closer than we used to be. I think Apple is the only remaining major holdout that doesn't handle name-constraints.
  - deleted 10y ago
    [deleted]
- tptacek 10y ago
  This is one of those ideas that sounds like common sense when you hear or think about it the first time, but falls apart on scrutiny. Ryan Sleevi has done a much better job picking it apart than I can here, but among the numerous problems with it: * The most important TLDs are transnational, and their trust hierarchies back into corporations (corporations, I will cheerfully and without irony point out, who are subject to the whims of the FVEY IC). * It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. * It consigns residents of countries with oppressive governments to total control by their governments, while at the same time making usage constraints based on those TLDs (such as local mandates to use services whose names end in .XX for XX in $bad_countries) much more powerful. * It further promotes the idea that security should somehow be tied to the DNS, despite the fact that the DNS is itself not transparently managed, and is often managed at odds with the interests of Internet users as a whole. * By factionalizing Internet trust, it harms interoperability and also makes it harder to introduce further constraints into the certificate system by essentially declaring up front that we're conceding Internet trust policy to individual nations. * It greatly complicates the security stories of companies that have adopted vanity domain names in random countries, which, whatever you think of those companies (koff! Pinboard), is an unforced error. Of all the things we can spend time on to improve Internet security, this is not one of the better ones.
  - r00fus 10y ago
    > * It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. Thomas, I simply don't get the promotion of policy over national jurisdiction. What non-national organization makes transnational policy that is remotely independent of the global constituency (ie, not corruptible or ineffective)? Nations create laws, back them up with armed forces. That's a proven model. The rest is a thin veil of cordiality over a situation best described as "lord of the flies". I predict (sadly) that the Internet will get balkanized in the next 10 years. GFW-style everywhere.
  - 0x0 10y ago
    The current system already places all trust in national TLD operators, because if a TLD DNS operator wants, they can fake the responses to NS (and recursively, MX) queries from a CA during the small time interval they head out to grab a certificate for your domain.
wtbob 10y ago
> Even if you pick a trustworthy CA, you're at the mercy of the weakest link (any random other CA elsewhere in the world). This was solved RFC 2692 & 2693, in 1999, and the entire industry has studiously ignored the solution and refused to use it. Had we paid attention, DNS would be secure — truly secure. But we don't, and every month we see another issue. Why? Cui bono?
- tptacek 10y ago
  This is the first I've heard about SPKI being an Internet-scale answer to the problem of X.509. The problem with the CA system isn't technical (even though X.509 truly does suck), but institutional: you can't have a single central authority handling all of Internet trust (it doesn't scale well, and it [rightfully!] alarms people), but if you have more then one, a market forms and generates a race to the bottom. Whether your certificates are sexprs or ASN.1, and no matter how many new features you bake into them, you're still going to have to solve the Internet trust distribution problem. The last thing in the universe you want is for Internet trust to somehow back out into the DNS. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/
  - 0x0 10y ago
    Not sure I agree with the DNSSEC rant. What we trust implicitly are the registrars (and they already manage the NS records for your domain even if you run your own primary DNS server), and the TLD and root-zone operators. If you cannot trust the registrars, then all is lost, because if your registrar account is breached (or your registrar is playing tricks on you), then whoever breached your registrar account (or, the registrar itself in case it's backstabbing you) is easily able to validate against any existing CA and obtain a HTTPS certificate. There is no additional security gained by having the CA roots external to the registrars, but it opens a huge avenue for attackers to obtain certificates without breaching your registrar, whether we're talking rogue CAs or evil TLDs. By merging the registrar and CA role (and preferably ensuring that for any given domain, the CA === the domain registrar), you eliminate all unrelated venues of attack. But you've always needed to trust your registrar (and TLD+root-zone operator). TL;DR: If DNS is untrustworthy then so is the current broken CA system because it emails validation tokens based on DNS MX records.
tptacek 10y ago
This is changing, and I think will change even more rapidly in the coming years. Two things are pushing that change: * Google is using Chrome's market share to push for Certificate Transparency, which is a monitoring system that allows Google (and everyone else) to supervise the issuance of certificates. Google has demonstrated that shenanigans at CAs will be used as a pretense to force the adoption of CT (or lose your place in Chrome's root store), and has repeatedly responded to problems by penalizing CAs. Being removed from Chrome (or Firefox) is basically the death penalty for a CA business. I don't love CT, but it's a clear step forward. * Certificate pinning is becoming more widely deployed. Pins allow browsers to do key continuity, the same way your SSH key works. For an individual user, key continuity is nice-to-have but not dispositive of the security issue. But across the whole user base, key continuity is very powerful: anyone deploying an abusive certificate risks being detected by the first browser whose pin is broken by that certificate, and when Google finds out, that could be the end of that particular CA. A third leg of this stool I'd personally like to see is a browser extension that allows users to opt in to certificate surveillance by trusted third parties (perhaps like ACLU, or perhaps from activist nerd groups) that themselves make fine-grained decisions about which CAs to trust for key Internet properties like Facebook and Google Mail. Ultimately, I think the major problem we have with TLS trust is not a protocol weakness (it's a shitty protocol, but whatever), but rather a user interface problem. We are essentially using the same TLS trust UX that the Netscape people came up with when they deployed SSL 2.0.

by 0x0 10y ago

TheDong 10y ago

A minimal first step would be to split CAs out into "per-tld" CAs. It would be a relatively easy change for browsers and ssl libraries to switch to saying "these Chinese authorities are only valid for .cn domains", or "these government CAs are only valid for .gov domains". That wouldn't be as good as something closer to what you suggest, but it would be a lot easier to implement and would help a decent bit. There are of course CAs that would remain global, and this wouldn't help if that's the large majority (Verisign, Digitrust, Comodo would be the obvious global ones)... but I believe there's a super longtail of CAs that honestly shouldn't be able to issue for most country TLDs.

alcari 10y ago
I wish we lived in a world where X.509 name constraints[0] were actually useful, but unfortunately we don't, and I think getting browsers (never mind other TLS clients) to enforce them is even less likely than the various root stores revoking known-bad CAs. [0]: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10
- wiml 10y ago
  We're closer than we used to be. I think Apple is the only remaining major holdout that doesn't handle name-constraints.
- deleted 10y ago
  [deleted]
tptacek 10y ago
This is one of those ideas that sounds like common sense when you hear or think about it the first time, but falls apart on scrutiny. Ryan Sleevi has done a much better job picking it apart than I can here, but among the numerous problems with it: * The most important TLDs are transnational, and their trust hierarchies back into corporations (corporations, I will cheerfully and without irony point out, who are subject to the whims of the FVEY IC). * It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. * It consigns residents of countries with oppressive governments to total control by their governments, while at the same time making usage constraints based on those TLDs (such as local mandates to use services whose names end in .XX for XX in $bad_countries) much more powerful. * It further promotes the idea that security should somehow be tied to the DNS, despite the fact that the DNS is itself not transparently managed, and is often managed at odds with the interests of Internet users as a whole. * By factionalizing Internet trust, it harms interoperability and also makes it harder to introduce further constraints into the certificate system by essentially declaring up front that we're conceding Internet trust policy to individual nations. * It greatly complicates the security stories of companies that have adopted vanity domain names in random countries, which, whatever you think of those companies (koff! Pinboard), is an unforced error. Of all the things we can spend time on to improve Internet security, this is not one of the better ones.
- r00fus 10y ago
  > * It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism. Thomas, I simply don't get the promotion of policy over national jurisdiction. What non-national organization makes transnational policy that is remotely independent of the global constituency (ie, not corruptible or ineffective)? Nations create laws, back them up with armed forces. That's a proven model. The rest is a thin veil of cordiality over a situation best described as "lord of the flies". I predict (sadly) that the Internet will get balkanized in the next 10 years. GFW-style everywhere.
- 0x0 10y ago
  The current system already places all trust in national TLD operators, because if a TLD DNS operator wants, they can fake the responses to NS (and recursively, MX) queries from a CA during the small time interval they head out to grab a certificate for your domain.

wtbob 10y ago

> Even if you pick a trustworthy CA, you're at the mercy of the weakest link (any random other CA elsewhere in the world). This was solved RFC 2692 & 2693, in 1999, and the entire industry has studiously ignored the solution and refused to use it. Had we paid attention, DNS would be secure — truly secure. But we don't, and every month we see another issue. Why? Cui bono?

tptacek 10y ago
This is the first I've heard about SPKI being an Internet-scale answer to the problem of X.509. The problem with the CA system isn't technical (even though X.509 truly does suck), but institutional: you can't have a single central authority handling all of Internet trust (it doesn't scale well, and it [rightfully!] alarms people), but if you have more then one, a market forms and generates a race to the bottom. Whether your certificates are sexprs or ASN.1, and no matter how many new features you bake into them, you're still going to have to solve the Internet trust distribution problem. The last thing in the universe you want is for Internet trust to somehow back out into the DNS. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/
- 0x0 10y ago
  Not sure I agree with the DNSSEC rant. What we trust implicitly are the registrars (and they already manage the NS records for your domain even if you run your own primary DNS server), and the TLD and root-zone operators. If you cannot trust the registrars, then all is lost, because if your registrar account is breached (or your registrar is playing tricks on you), then whoever breached your registrar account (or, the registrar itself in case it's backstabbing you) is easily able to validate against any existing CA and obtain a HTTPS certificate. There is no additional security gained by having the CA roots external to the registrars, but it opens a huge avenue for attackers to obtain certificates without breaching your registrar, whether we're talking rogue CAs or evil TLDs. By merging the registrar and CA role (and preferably ensuring that for any given domain, the CA === the domain registrar), you eliminate all unrelated venues of attack. But you've always needed to trust your registrar (and TLD+root-zone operator). TL;DR: If DNS is untrustworthy then so is the current broken CA system because it emails validation tokens based on DNS MX records.

tptacek 10y ago

This is changing, and I think will change even more rapidly in the coming years. Two things are pushing that change: * Google is using Chrome's market share to push for Certificate Transparency, which is a monitoring system that allows Google (and everyone else) to supervise the issuance of certificates. Google has demonstrated that shenanigans at CAs will be used as a pretense to force the adoption of CT (or lose your place in Chrome's root store), and has repeatedly responded to problems by penalizing CAs. Being removed from Chrome (or Firefox) is basically the death penalty for a CA business. I don't love CT, but it's a clear step forward. * Certificate pinning is becoming more widely deployed. Pins allow browsers to do key continuity, the same way your SSH key works. For an individual user, key continuity is nice-to-have but not dispositive of the security issue. But across the whole user base, key continuity is very powerful: anyone deploying an abusive certificate risks being detected by the first browser whose pin is broken by that certificate, and when Google finds out, that could be the end of that particular CA. A third leg of this stool I'd personally like to see is a browser extension that allows users to opt in to certificate surveillance by trusted third parties (perhaps like ACLU, or perhaps from activist nerd groups) that themselves make fine-grained decisions about which CAs to trust for key Internet properties like Facebook and Google Mail. Ultimately, I think the major problem we have with TLS trust is not a protocol weakness (it's a shitty protocol, but whatever), but rather a user interface problem. We are essentially using the same TLS trust UX that the Netscape people came up with when they deployed SSL 2.0.