
Chinese CA WoSign faces revocation after possibly issuing fake certificates - tombrossman
http://www.percya.com/2016/08/chinese-ca-wosign-faces-revocation.html
======
michaelt
Traditionally it's difficult for browser vendors to revoke a root CA as they
want to grandfather in old certificates, so existing sites don't have the rug
pulled out from under their feet when their only crime is using a crap CA.

Partial solutions include blocking the CA's certs based on the issuance date
or insisting they hand over a list of the certs they've issued - but if the CA
is going down in flames anyway, they have no incentive to cooperate; they can
backdate certs and destroy their own customer list.

My theory is [1] this is one of the side benefits of Certificate Transparency
- CT will give browser vendors a list of certs to grandfather in if they
decide to shut down a CA against its will.

[1] [https://www.mjt.me.uk/posts/certificate-
transparency/](https://www.mjt.me.uk/posts/certificate-transparency/)

~~~
Buetol
+1 revoking a CA using the issuance date seems like the right solution

~~~
michaelt
It would certainly be better than nothing, yes.

But prior to March 2015, CAs could issue certs valid for up to 5 years. So
even if browsers stopped accepting WoSign certs with an issuance date after
today, WoSign could still issue certs "issued March 2015 valid until to March
2020" and browsers would accept them.

~~~
jandrese
If they start putting fake dates on the certs then the nuclear option is the
only option. They are in the business of selling trust and they're outright
lying on their only product? That's untenable.

~~~
creshal
See above, they've already been caught doing that.

------
mtgx
> Possible fake cert for Github
> [https://crt.sh/?id=29647048](https://crt.sh/?id=29647048)
> [https://crt.sh/?id=29805567](https://crt.sh/?id=29805567)

> Possible fake cert for Alibaba, the largest commercial site in China
> [https://crt.sh/?id=29884704](https://crt.sh/?id=29884704)

> Possible fake cert for Microsoft
> [https://crt.sh/?id=29805555](https://crt.sh/?id=29805555)

Yikes. If all of that is true, surely Google will _permanently_ ban WoSign
from Chrome? And I would hope Mozilla and Microsoft, too, but Google is
usually the one to "play tough" with rogue CAs (and I hope they will strive to
_develop and maintain_ that reputation).

~~~
verroq
[deleted]

~~~
laggyluke
I believe this is done by not accepting any certificate issued past date X.
This way the old certificates keep working, while the new ones don't.

~~~
willglynn
This is problematic here, because WoSign is also known to have issued a
certificate in July 2016 backdated to December 2015:

[https://groups.google.com/d/msg/mozilla.dev.security.policy/...](https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/mKSMaz9eCgAJ)

------
jaas
This is a pretty misleading title for a couple of reasons:

1) WoSign may face revocation (I doubt it but I don't know), but there is no
evidence of that in this article. This is just one person not affiliated with
a root program "calling for" it. People on the internet call for revocation of
major CA roots all the time.

2) I don't really know what a "fake" cert is, it's a very strange choice of
words. I would think a fake cert is not a real cert, and in that case issuing
fake certs is fine because browsers won't trust them. It seems the problem
here is that _real_ certs were issued when they shouldn't have been. That's
called "mis-issuance", not "fake certs."

~~~
joosters
_I don 't really know what a "fake" cert is_

You are just being pedantic. The meaning is perfectly clear, they are creating
certificates for a domain and giving them to people who do not control/own
that domain. Pick whatever word you like to describe this. The story is very
clear.

~~~
SimeVidas
Speak for yourself. People get confused by the smallest ambiguities.

------
jwilk
[https://www.schrauger.com/the-story-of-how-wosign-gave-me-
an...](https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-
certificate-for-github-com)

------
koolba
Too big to fail my ass. There's no such thing when it comes to security. If
anything, that's more reason to cut them loose.

If a CA pulls shit like this they need to be revoked immediately and let the
wrath of 1000s of businesses that are impacted by cert warnings rain down upon
them. That will 1) Solve the security problem immediately and 2) Publicize
what it means to get a cert from a crap CA that doesn't care about security.

Sure it will suck for the "little guy" who didn't know but, if you don't do
this, he'll never know and never learn.

~~~
mariuolo
I won't comment on the specifics of this case, but a more nuanced approach
regarding security is preferable because it favours transparency.

If a vendor/CA/whatever knows that they will die if anything comes out, they
will bury things like this even deeper.

~~~
koolba
> I won't comment on the specifics of this case, but a more nuanced approach
> regarding security is preferable because it favours transparency.

Certificate Transparency solves a lot of this already. It'd be nice if you
could flag your domain as being only acceptable from a CA of your choosing. I
don't even think the false positives would be an issue as worst case you have
security conscious customers not coming to your site (i.e. you make the
business decision).

> If a vendor/CA/whatever knows that they will die if anything comes out, they
> will bury things like this even deeper.

There's already ways to handle this. Rather than signing everything with your
top level cert, you sign a series of intermediate certs and use those to sign
the end user keys. The intermediate certificates would be rolled over every N
days and creation of new ones should happen offline (i.e. where you keep your
master CA cert, the "approved" one).

If you have a system like that in place _before_ shit hits the fan, the damage
is isolated to the impacted intermediate certs which could be selectively
revoked/blacklisted. If a CQ has not taken those precautions then they've got
no recourse when something like this happens.

From a user's perspective, I wouldn't want my browser/OS/app to trust any
certificates from these losers. If they can't isolate the damage that's their
and their customer's problem. I'm not going to compromise my security for
their sake.

~~~
pfg
> It'd be nice if you could flag your domain as being only acceptable from a
> CA of your choosing.

HPKP pretty much solves this, and is already being used by a large number of
high-value targets.

DNS Certification Authority Authorization (CAA) would also be fairly useful in
this regard. It's essentially a DNS record set by a domain owner declaring
which CAs are allowed to issue certificates for that domain. These records can
then be checked by CAs prior to issuing certificates. It's more or less a
defense-in-depth mechanism for other domain validation vulnerabilities, and
would've probably prevented these incidents if implemented correctly, though
not particularly useful if a CA is compromised completely. I suppose it could
also be used by Certificate Transparency Monitors to automatically check if
issued certificates are suspicious.

Unfortunately, it's not mandatory yet and so far I believe only a small number
of CAs have adopted CAA (Let's Encrypt, DigiCert and possibly some others).

> Rather than signing everything with your top level cert, you sign a series
> of intermediate certs and use those to sign the end user keys.

This is what CAs already do, including WoSign. I'm not sure if signing end-
entity certificates with the root key is even allowed by the Baseline
Requirements. Unfortunately, having multiple intermediate certificates to
limit the number of affected clients does not really help much if the question
is whether a CA should be trusted at all due to their track record, which is
what we're talking about here.

------
guelo
I just went to delete these roots from my Windows system but it's not listed.
It was in Firefox's list but not in Window's. Anyone know why?

~~~
hannob
They're cross-signed by startcom.

~~~
guelo
I'm not familiar with this. Does it mean that if you trust StartCom you have
to trust WoSign?

~~~
detaro
No, you can explicitly install the WoSign certificate into the "Untrusted
Certificates" chain.

------
0x0
So what's the relation to StartCom/StartSSL? I remember reading some comments
about half a year ago mentioning that the startssl website suddenly was hosted
on Chinese IP addresses, just around the time they redesigned the web page.
This seemed fishy enough back then that I finally switched from startssl to
letsencrypt for non-wildcard certs and actually started paying a different CA
for wildcart certs...

Did the StartSSL root CA change hands / was it sold to a Chinese company
(Wosign?)

I seem to remember the CEO used to be vocal in various ssl and ca forums and
on bugzilla earlier.... But no comments lately?

~~~
psz
Looks like Eddy Nigg was recently attending the cabforum minutes:
[https://cabforum.org/2016/06/09/2016-06-09-minutes/](https://cabforum.org/2016/06/09/2016-06-09-minutes/)

~~~
0x0
From what I've seen earlier, he's appeared to have a clue or two about SSL. I
wonder what's going on with wosign+startssl despite that? Isn't it all very
related?

------
amluto
Can't browsers at least restrict CAs like WoSign so that their roots are only
accepted for .cn domains?

I realize that X.509 name constraints are utterly broken, but that doesn't
mean that browsers can't manually restrict the domains that a given root is
accepted for.

------
marcoperaza
Is there an easy way for me to revoke trust from all Chinese CAs? Anyone in
China is ultimately subject to being forced to do the dirty work of the
Chinese Communist Party. Why are browser and OS vendors even trusting them in
the first place?

~~~
aianus
I untrusted all Chinese-sounding CAs from "System Roots" under "Keychain
Access" in OSX as soon as I got my laptop. That's what Chrome and Safari
verify against.

~~~
Kadin
That wouldn't have helped you in this case -- WoSign doesn't even show up in
the OS X or Windows root keystores. Its certificates are (apparently) signed
by StartCom.

I just blacklisted StartCom's root certs. IMO for signing off on WoSign
they're just as guilty, if not worse, than WoSign itself. Since they're the
ones with the root cert in the OS, the buck stops there.

~~~
rblatz
I attempted to remove all StartCom certs from the OS X keychain, apparently
you can't do it even as root. You have to boot into the recovery partition
first.

[http://superuser.com/questions/1070664/security-
seckeychaini...](http://superuser.com/questions/1070664/security-
seckeychainitemdelete-unixoperation-not-permitted-on-os-x-when-tryi)

Edit: Don't delete them, instead right click each certificate, select "Get
Info", Expand the "Trust" panel, and set it to "Never Trust"

~~~
aianus
You don't have to remove them, you can just set the 'Trust' setting to 'Never
Trust'.

~~~
joosters
I can't remember whether it was MacOS or Windows, but at least one OS will
sometimes re-install a 'standard' CA certificate if you delete it. Setting
'never trust' is the most reliable way to kick out the CA as it ensures that
it stays out.

