Certificate Authority Gave Out Certs for GitHub to a GitHub Account Holder
techdirt.com
techdirt.com
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.
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.
* 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.
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.
[1]: https://www.icann.org/registrar-reports/accredited-list.html
If we can engineer that somehow, then it wouldn't matter how many thousand registrars (or CAs) there are, because you only need to trust the one you picked to register your domain at.
If we can't trust the .COM operators to manage their accredited registrars properly then YES we need to distrust all of .COM, because then anyone could get a cert for any .COM by way of a single shady registrar. This trust is already a prerequisite for today's CA system.
I am simply suggesting putting additional limits in place so that instead of trusting the .com TLD ops AND the relevant registrar AND all of the CAs in the world, we merely need to trust the .com TLD ops and the relevant registrar. It is strictly a subset of today's trust circle.
Edit to add: today we are paying and trusting CAs to verify domain ownership by way of insecure DNS lookups (and then email tokens or http challenges). This is absurd because domain ownership is already positively definitively proven in the registrars' customer databases and the TLD's registrar database
Edit2 to add more: The entire SSL CA ecosystem security hinges on the single web form for modifying NS records for a given domain at a given registrar for a given TLD. If you have access to modify the NS records you have all you need to get a certificate. So: This particular web form is where we should put a button to download SSL certificates. And, we should engineer clients to verify that certificates are issued only from that particular source (registrar at a registry). And get rid of external CAs.
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?
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.
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.
* The FVEY IC gains de jure control over the TLS keys all of the Internet's most important sites, including (along with the COMs and NETs and CO.UKs) every .IO host.
* It immediately becomes impossible for Google to use CA-level revocation to punish shenanigans (Google can't "revoke" .COM, or, for that matter, leave it.)
It is mind-boggling to me that a community that is so animated by the Snowden disclosures and the leaks of the Equation Group exploits could entertain the idea of DNSSEC even for a moment.
Also I wouldn't mind people thinking twice about the implications of using .ly and others as their home on the internet. Why shouldn't geopolitical TLDs mean something? It would allow end users to make a more informed decision on trusting a particular website, more than today's system.
We would still allow multiple registars for both generic TLDs and national TLDs. And Google could very well implement a blacklist for registrars that have turned out to be mischievous, similar to the safe browsing service they already have. Or the TLD operators could kick out the unserious registrars from their TLD registry.
And domain registrants would shun unserious registrars like crazy if google started blacklisting particular registrars.
Edit: To clarify, a "registrar" is not a TLD operator but one of many companies with access to the TLD database, taking domain registrations on behalf of the TLD. I think it's important that TLDs still delegate registration to multiple independent, approved registrars like it is today.
Edit2: Today, you are trusting: (#1.) that the registrar or TLD operator or root zone operator doesn't fool around with your NS records or they could redirect SSL purchases to themselves for your domain and (#2.) that not a single CA in the world produces an improper certificate for your domain regardless of #1.
With my suggestion, you no longer need to trust #2, but you still need to trust #1. Which is better than today's situation.
> * The FVEY IC gains de jure control over the TLS keys all of the Internet's most important sites, including (along with the COMs and NETs and CO.UKs) every .IO host.
Please prove the above assertion.
Everytime I see you post something about DNSSEC I ask you these same questions and I've never gotten a response from you that elucidates this link. What is it exactly about DNSSEC that you think it gives controls to world governments? Spell it out for me in as much detail as possible.
Verisign is the registry for .com and .net. PIR is the registry for .org. Neustar is the registry for .us. What exactly do you mean by the US controls them? Do you mean that because they are on US property and operate in a US jurisdiction that the USG controls them?
In that case wouldn't it be fair to say that any US concern operating in USG jurisdiction(e.g. Comodo, Google, Mozilla, Let's Encrypt) are also controlled by the USG? Or is there something specific about DNS registries that makes them special?
The way to keep government controls away from your own cryptographic trust negotiation is not to not implement DNSSEC but to implement your own DNS root with its own DNSSEC* , or to implement your own orthogonal trust negotiation such as the various PKI models currently in use.
[* ] Before anyone argues, this is exactly what you do when you host a domain in your own DNS server. The vast majority simply defer the rest of the DNS to 3rd party resolvers. I'm sure DNSSEC is able to cope with a situation wherein you own and host only a subdomain and keep the DNS hierarchy above you from being able to override or in any way interfere with your DNSSEC controls.
Again I am confused by this statement which you take for granted. Prove it.
You're not the only one, and that's the problem. It has been, for nearly twenty years now.
> 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.
The problem is that we already have a single point of truth: ICANN. And the problem is that we have multiple points of truth: every single CA out there is trusted for the entire Internet.
If you trust letsencrypt, you ultimately rely on ICANN. If you trust StartSSL, you ultimately rely on ICANN.
The virtue of SPKI is that it forces one to be honest with oneself. The owner of com really does own every single hostname under com; why not be honest about that? The owner of cn really does own every single hostname under cn; why not be honest about that? Why create a system where entities who can be legally compelled by any two-bit nation-state which can pay for a guy with a rubber hose are trusted for the entire world, rather than only for their two-bit nation-states?
Government-controlled PKI doesn't bother me, because ultimately every PKI is controlled by governments, because governments have a monopoly on force. AC Camerfirma S.A. is in my certstore; they are a firm in the Kingdom of Spain, and the King or any of his government are at liberty to compel AC Camerfirma S.A. to produce a certificate for google.com or news.ycombinator.com at any time they wish.
So I am trusting the King of Spain and his government with the security of my connexion to Google, an Alphabet company with servers located in the U.S. That's … insane.
Per your article's comment, 'Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys': Gaddafi did ultimately control bit.ly's TLS keys, as indicated in 2010 when his government shut down vb.ly. They could have, had they wished, pointed that domain name at servers they controlled and requested a StartSSL certificate; today they could do the same for a letsencrypt cert.
DNSSEC is probably a mistake for other reasons, but a SPKI-based system in which hosts received certificates from their domain name providers, from their IP address providers and from their legal places of registration would have been superior to our current system, in which any host may be certified by any CA anywhere.
* 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.
Android 4+ allows you to disable certificates from the system Settings and root isn't required, so try that first if you want to manually mess with the certificates. The app won't work with Android 4+ anyway.
An app to manage security certificates on your phone also containing a version of the Android CACert keystore derived from Mozilla. If a certificate has recently become untrusted you can either install an update to this app or you can backup and remove certificates by yourself.
(For the obvious issue) WoSign's recent certificates are in the CT logs and they're promising to put in all their 2015 certificates as well, so they could be whitelisted.
Some people are also calling for every certificate they've ever issued to be added to the CT logs, but I doubt that'll happen.