
Certificate Authority Gave Out Certs for GitHub to a GitHub Account Holder - okket
https://www.techdirt.com/articles/20160825/12181835347/certificate-authority-gave-out-certs-github-to-someone-who-just-had-github-account.shtml
======
0x0
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
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.

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

~~~
0x0
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.

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

~~~
0x0
I did not argue for TLD-as-CA, but registrar-as-CA :)

~~~
pfg
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](https://www.icann.org/registrar-reports/accredited-list.html)

~~~
0x0
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.

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

~~~
0x0
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.

~~~
tptacek
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?

~~~
0x0
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.

------
alcari
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...](https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/k9PBmyLCi8I)

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

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

~~~
0x0
One of the problems here was that they were back-dating certificates...

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

------
bendbro
I think the same thing happened to letsencrypt

~~~
krussell
You may be thinking of a similar vulnerability discovered with StartSSL's
StartEncrypt tool - [https://www.computest.nl/blog/startencrypt-considered-
harmfu...](https://www.computest.nl/blog/startencrypt-considered-harmful-
today/) .

