
CA:WoSign Issues - danielsiders
https://wiki.mozilla.org/CA:WoSign_Issues
======
Analemma_
So, can I ask an awkward question? Realistically speaking, is there _any_
chance that a large CA would ever actually be removed from Mozilla's store, no
matter how severe their malfeasance?

I started wondering this after they declined to remove StartSSL after the
Heartbleed fiasco, and while I sort of understood the reasoning there in
isolation, between that incident and this long list of WoSign violations, I'm
really getting the sense that CA's are "too big to fail" and that the
downsides of suddenly breaking huge parts of the internet on unsuspecting
users mean that the threat of removing badly-behaving CA's is an empty one.
What would a CA have to do to _actually_ be removed, especially if they were
to sign really huge sites?

~~~
revelation
CAs have been caught issuing CA=YES certificates and Mozilla have done
nothing.

[https://bugzilla.mozilla.org/show_bug.cgi?id=724929](https://bugzilla.mozilla.org/show_bug.cgi?id=724929)
WONTFIX

~~~
jasonjei
I think Chinese CAs are also special cases. If American browser vendors remove
a Chinese CA like WoSign, there is the possibility a fork distribution will
replace Mozilla in China by inclusion of these certificates. I think it would
take the cooperation of the Big 4 browser/OS vendors to remove a CA, and the
Chinese market often responds by creating its own internal distribution.

~~~
amluto
But Firefox probably could name-constrain WoSign to .cn. Firefox could
probably also name-constrain all StartCom-issued certificates after some cut-
off-date to .cn or just ban new StartCom-issued certificates entirely.

~~~
tptacek
Reprising a previous comment about this suggestion:

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.

~~~
idlewords
Let's see if you still think my .IN "vanity" domain is a mistake come November
9. I'm putting my chips on the world's biggest democracy!

~~~
tptacek
HE'S NOT GOING TO WIN EVERYTHING WILL BE FINE SHUT UP

------
azdle
Does anyone know if it's possible to write a Firefox add-on that could warn
you that the site you're connecting to uses one of these less trustworthy or
esoteric CAs? I've looked through the APIs, but I don't see any hooks for that
kind of info.

EDIT: Now that I think about it, it must be possible, Certificate Patrol is
looking at the cert info, I'll see how they do it.

~~~
gkoberger
You could probably use the website URL + an API (such as
[https://www.ssllabs.com/projects/ssllabs-
apis/](https://www.ssllabs.com/projects/ssllabs-apis/))? There might be a
better way, though.

~~~
Retr0spectrum
If someone shady was MITMing your traffic, they could just block access to the
API. If you wanted to do the checks before loading each URL, it would make
things very slow.

------
mtgx
I'm starting to think that a service such as SSL Labs should also grade CAs
(perhaps by looking through Certificate Transparency logs as well, once all
CAs have to use them).

Then if you use like a "C-rated" CA, your HTTPS score is also limited to B. A
B-rate CA would limit your HTTPS score to A, and only an A-rated CA would
allow you to get A+ on SSLabs. Something along those lines.

I imagine rating the CAs would be quite a complex task, but they could start
with the big ones first that own 80-90% of the market.

~~~
Klathmon
For that to be useful, browser vendors would have to start showing something
other than a binary "secure" "not secure" setup to the user along with some of
that info.

Also, it sounds like something that will be very easy to corrupt.

~~~
jo909
SSL Labs is a tool mainly used by the website owners/administrators, not so
much by end users (and if at all an end user will then complain to the owner
about a low rating).

Downgrading the rating because he used a "fishy" CA might motivate the website
owner to switch to a CA with better standing. The bad CA will feel pressure to
clear their standing.

------
drdaeman
> For example, a cert where the owner validated "netwi.ru" was able to add
> "mx.idisk.su", an entirely different domain, without validating it.

Now that's odd, because I know those two domains. I've even requested some
certificates for them myself before (never had anything odd - I think I
would've noticed if there was a way to add a domain without validation), but I
left the company in January 2015.

It was my coworker requesting that certificate, and I've just found - still
have the access to the servers as I help them with small issues on rare
occasions - that at the same date it was issued (Feb 26, 2015) he had most
certainly got a validation file (idisk.su.html) and put it into idisk.su's
static root.

Webserver logs are, of course, long gone so can't really tell if it was
actually accessed or not, but I think when I had requested certificates myself
it was a wizard-style process where one got a file to download and the only
next action was to validate it, no other way to proceed.

I mean, at least he got the file and put it there, in a proper place. And it's
also weird that the certificate in question
([https://crt.sh/?id=29805560](https://crt.sh/?id=29805560)) had included
another idisk.su subdomain (mail.idisk.su) that wasn't marked as not validated
in the report
([https://www.wosign.com/report/wosign_incidents_report_090420...](https://www.wosign.com/report/wosign_incidents_report_09042016.pdf;)
page 13).

I don't doubt there was a severe bug. But this leaves me wondering whenever
the analysis followed was really accurate (not saying it wasn't, but still
sort of curious that it could be).

------
devy
Where WoSign have demonstrated glaring incompetence and utter ignorance of
security practices as an CA, I doubt these issues aren't violated at quite a
few dozens of other CAs. These are good lessons for other CAs.

To me, the ultimate question is this: if we are trusting CAs as the 3rd party
entity in order to make PKI schemes work, then who's going to be auditing the
"supposedly trustworthy" party?

~~~
joepie91_
I've at least started a list of CA incidents here, to try and make this a bit
more transparent: [https://git.cryto.net/joepie91/ca-
incidents](https://git.cryto.net/joepie91/ca-incidents)

Contributions are more than welcome.

------
newman314
While I've seen some scripts to "blackhole" so-called bad/suspicious CAs, I
have yet to find something that cleans things across the board for different
browsers.

Apple's implementation of "Rootless" while useful for other things hasn't
helped by denying the ability to remove certs unless one reboots into recovery
and does "csrutil disable".

------
themihai
Hopefully one day we will replace CAs with something decentralized(i.e based
on DNSSEC). CAs make sense only if you need an EV certificate.

~~~
Panino
DNSSEC is _not_ decentralized -- it follows a _strict_ hierarchy from ICANN =>
TLDs (world governments) => you.

DNS is _distributed_ , not decentralized.

~~~
themihai
Right... but at least you cut off the CA from the scheme. You depend on ICANN
-> TLD anyway.

