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

by okket • 10 years ago

109 38 10 years ago

techdirt.com

0x09• 10 years 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• 10 years 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.

alcari4• 10 years 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

tptacek6• 10 years 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.

wtbob2• 10 years 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?

tptacek6• 10 years 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/

tptacek6• 10 years 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.

andrewflnr2• 10 years ago

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.

akerro• 10 years ago

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.

alcari4• 10 years ago

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.

0x09• 10 years ago

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

mjevans• 10 years ago

If a CA 'lies' we shouldn't trust anything they've ever said anymore. That's why they should be de-listed.

andrewflnr2• 10 years ago

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.

bendbro• 10 years ago

I think the same thing happened to letsencrypt

lfam• 10 years ago

Citation?

krussell• 10 years ago

You may be thinking of a similar vulnerability discovered with StartSSL's StartEncrypt tool - https://www.computest.nl/blog/startencrypt-considered-harmfu... .

alcari4• 10 years ago

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

Certificate Authority Gave Out Certs for GitHub to a GitHub Account Holder

Related Stories