Certificate Authority Gave Out Certs for GitHub to a GitHub Account Holder(techdirt.com)
techdirt.com
Certificate Authority Gave Out Certs for GitHub to a GitHub Account Holder
https://www.techdirt.com/articles/20160825/12181835347/certificate-authority-gave-out-certs-github-to-someone-who-just-had-github-account.shtml
4 comments
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.
* 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.
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.
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.
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.
* 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.
> * 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.
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.
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.
That's exactly why the solution is neither the current CA system nor the CA-per-TLD (or TLD-as-CA) model, but rather one with full transparency with regards to issuance and wide adoption of key pinning.
I did not argue for TLD-as-CA, but registrar-as-CA :)
There are thousands of accredited registrars out there[1], how is that going to improve anything? I don't even want to get into the fact that the majority of them are not ones that I would call infosec companies.
[1]: https://www.icann.org/registrar-reports/accredited-list.html
[1]: https://www.icann.org/registrar-reports/accredited-list.html
There would have to be some sort of way to ensure that a registrar couldn't act as a CA for a domain they aren't the registrar of.
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 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.
Such a system would require either centralized trust anchors, massive preload lists, or be trust-on-first-use. In other words, you're just reinventing variants (and combinations) of DANE or HPKP.
At least we'd get rid of the silly and fragile "domain ownership verification", which is often email based and therefore dependent on DNS MX record security - or in the case of ACME/LetsEncrypt usually DNS A records for HTTP, which is a totally ridiculous exercise since the registrar already knows you are the owner of the domain.
Your suggestion doesn't get rid of any current problems, and adds the new problem that you're chained to one authority for your TLD. If Google comes to distrust the COM operators, what does it do? Switch to GOOGLE.ZA?
There are many .COM registrars so I'm not sure what you're getting at. Obviously we are trusting the .COM TLD operators to have implemented appropriate ACLs in the .COM database so that registrars can't meddle with other registrars' domains. And if they haven't, well, we're back to square one: External CAs use DNS to verify domain ownership, which is silly and insecure; meanwhile the .COM zone knows who is the registrar for any given domain, and the registrars know who is the owner of a given domain.
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.
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.
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
[0]: https://tools.ietf.org/html/rfc5280#section-4.2.1.10
We're closer than we used to be. I think Apple is the only remaining major holdout that doesn't handle name-constraints.
[deleted]
> 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?
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?
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/
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/
> This is the first I've heard about SPKI being an Internet-scale answer to the problem of X.509.
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.
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.
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.
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 post directly addresses this concern. I'll stick by those arguments. But I'll add these: by merging the registrar and the CA role, two things immediately happen:
* 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.
* 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.
If registrars were the only valid CA for a domain and clients could somehow validate this, then we'd remove the "insecure SMTP" from the equation.
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.
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.
Could you elaborate on the link between DNSSEC and the FVEY?
> * 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.
> * 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.
DNSSEC is adding a cryptographic-trust-negotion layer to DNS. Governments are in control of DNS, ergo governments would be in control of the new layer which DNSSEC adds to it. DNSSEC is adding a means of cryptographically verifying the government control already implicit in DNS.
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.
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.
>Governments are in control of DNS
Again I am confused by this statement which you take for granted. Prove it.
Again I am confused by this statement which you take for granted. Prove it.
I remain confused by this question. The USG controls COM, ORG, NET, and US. The UK government, host of GCHQ, the world's most unhinged SIGINT agency, controls CO.UK, NET.UK, and IO.
> The USG controls COM, ORG, NET, and US.
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?
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?
Here's a thread from mozilla.dev.security.policy where the CA responds to this and two other(!) misissuance incidents they failed to report (someone's even claiming a third incident at the end):
https://groups.google.com/forum/#!topic/mozilla.dev.security...
We need to start just de-trusting CAs that do this crap. Yes, websites will break. That will put pressure on site owners to only choose responsible CAs, and that market pressure is the only thing that can solve this problem.
We can do it without breaking websites: a TLS implementer could reject all certificates issued by a particular CA after a certain date.
(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.
(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.
One of the problems here was that they were back-dating certificates...
That's what I included "for the obvious issue": even in the backdated certificates they still have "reasonable" notAfter dates, and we (will) have a list of every certificate they've issued in the relevant time span.
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.
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.
https://f-droid.org/repository/browse/?fdfilter=cert&fdid=in...
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.
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.
If a CA 'lies' we shouldn't trust anything they've ever said anymore. That's why they should be de-listed.
Of course, that too. I guess most of my point was to handle the pragmatic "but you'll break everything" objection. You can't quite dismiss this out of hand on principle alone, as much as I'd like to.
I think the same thing happened to letsencrypt
You may be thinking of a similar vulnerability discovered with StartSSL's StartEncrypt tool - https://www.computest.nl/blog/startencrypt-considered-harmfu... .
Citation?
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.