
Final Removal of Trust in WoSign and StartCom Certificates - selectnull
https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/FKXe-76GO8Y
======
jbergstroem
Speaking of removing trust bits; the ever-delayed Symantec saga continues with
no clear decision.

What concerns me is:

\- the lack of public communication, as shown here (tl;dr: private meetings):
[https://groups.google.com/forum/#!topic/mozilla.dev.security...](https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/k3PaF0UoE0I)

\- the contrast between symantec and the mozilla security groups path forward
[as well as how its communicated]
([https://groups.google.com/d/msg/mozilla.dev.security.policy/...](https://groups.google.com/d/msg/mozilla.dev.security.policy/C45hQChFLyc/4HyG0iaMBAAJ),
[https://www.symantec.com/connect/blogs/symantec-s-
response-g...](https://www.symantec.com/connect/blogs/symantec-s-response-
google-s-subca-proposal))

~~~
ivanr
I don't think you're being fair toward Mozilla. They had a meeting with
Symantec and reported on it; there were no details because Symantec is going
to soon publish everything. They probably had the meeting only because Gerv
was in the area. Mozilla have been transparent the whole time.

Google's approach is clearly different to that of Mozilla, but IIRC they have
never pledged transparency. They're a commercial entity and they're doing what
they think is right and/or is in their interests.

~~~
jbergstroem
I can understand how my comment might have come off as somewhat judgmental (to
either side) but that was not my intention. The idea was to [without derailing
the thread too much] give people interested in certificate issues a relatively
quick summary on what has happened and my concern about it.

------
JoshTriplett
And meanwhile, Let's Encrypt is on track to offer wildcards at the start of
next year ([https://letsencrypt.org/2017/07/06/wildcard-certificates-
com...](https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-
jan-2018.html)), so one of the last reasons to need a non-LE cert is going
away.

I used StartCom for years, but LE made it completely obsolete for me. And
StartCom seems to have been willing to throw it all away with the WoSign
acquisition.

~~~
justinclift
Lets Encrypt seems like a good solution for the https cert side of things.

Wish there was an equivalent thing for signing executables. eg for the
binaries of our software releases.

We'd been using StartCom signing certs (for Win binaries) up until this
clusterf __k. ;)

~~~
ktta
There's always GPG signing.

~~~
khedoros1
Does that provide the same integration into Windows that Authenticode does?
Plus timestamp, dualsign, and cross-sign?

~~~
ktta
>Does that provide the same integration into Windows that Authenticode does?

Nope

------
xoa
I'm still really bummed about StartCom's suicide/implosion. They had by far
the most sane and reasonable pricing model I've ever seen, and one I really
wish someone else would do. They basically only charged for non-automatic
authentication, not for what you _did_ with that authentication, and then let
each level of authentication feed into higher levels. So Level 1 machine auth
(similar in spirit to LE) was entirely free, you could verify an email,
domain, or whatever and then produce certs for that. If you wished you could
pay money (~$60 for 2 years IIRC) to have an actual human look at your
documentation and give you a call, then give you a Level 2 with your legal
name. You could then use that for an unlimited number of S/MIME certs for
email accounts, domains, software signing and so forth. Having gotten personal
verification to level 2, you could then pay to have an organization certified.
Etc.

Their UI wasn't the best, but it was functional and the overall system made a
lot of sense. They didn't put an artificial price on some bits with a marginal
cost of nada. It's a real shame all that got flushed, because that model of
business filled a hole that has no general world solution right now (in
principle authentication of their citizens should be a core role and offering
of modern government, but I'm not holding my breath there).

~~~
ivanr
You're forgetting that they had a charge for revocation, which was also
automated. Even after Heartbleed, they refused to revoke the potentially
compromised certificates without being paid. They also advertised their
certificates as 100% free, even though they clearly weren't (because of the
revocation charges). The certificates were not free for commercial purposes
either.

IMO, just like one of those schemes where you don't pay to get in, but you
have to pay to get out.

It's a shame, because they could have achieved a market share similar to Let's
Encrypt, if only they had played their cards slightly differently.

~~~
xoa
> _You 're forgetting that they had a charge for revocation, which was also
> automated._

I did not forget that, I was just talking about the authentication and
certificate issuance side. But though it didn't fall under the umbrella of
authentication it is something that actually cost real money at that point.
You misunderstood the situation and how revocation functioned in a way that's
extremely important (since it's finally getting fixed but the improvements
could use more widespread deployment). The original certificate revocation
mechanisms, CRL and OCSP, are and always have been completely broken in terms
of fundamental scaling and failure modes. Scott Helme just did an excellent
summary on the situation and upcoming developments [1] which I strongly
encourage you to read, but in essence due to the way they work _seriously_
offering CRL/OCSP (as in, in a way that won't instantly die when someone
breaths on it hard) services and adding certs to them requires significant
distributed infrastructure, which has not always been cheap. They were bad
approaches even with that though due to other practical failure modes that
were beyond a CA's control anyway. Both stink to the point that many (most?
all?) operating systems/applications/browsers just soft fail by default or
even ignore them entirely. "Revocation" for the wider web has largely been a
mirage.

StartCom did in fact have an explainer about this at one point, and their
position was reasonable. Other CAs hid the cost in large part by charging a
ridiculous amount for every cert issuance, despite many people never actually
needing revocation services. StartCom let you have as many certs as you wanted
after authentication for free, but if you lost one in such a way that you
needed to make use of CRL/OCSP then you were charged. Users could pay that
price, or alternatively invest in other ways to mitigate at their discretion
rather then just getting charged no matter what.

If StartCom had survived until now, or if someone else adopted their model,
then I'd expect at this point they'd make use of modern techniques like OCSP
Must-Staple/Expect-Staple, CAA, CT, etc. by default, and in turn that problem
would be solved at no cost.

> _IMO, just like one of those schemes where you don 't pay to get in, but you
> have to pay to get out._

This is completely ridiculous. Nothing inherently made anyone lose private
keys. Even Heartbleed didn't defeat someone using an HSM for example. Nor
would everyone who lost a private key need try to publicly revoke (to the
extent that would even work). Given the cost tradeoffs this was one particular
standards design failure that has been and remains wrong to make into some
general insurance vs letting individuals have the freedom to deal with it as
needed and/or having the standard itself fixed.

\----

1: [https://scotthelme.co.uk/revocation-is-
broken/](https://scotthelme.co.uk/revocation-is-broken/)

~~~
ivanr
Whether revocation works has nothing to with my point about StartCom, which is
that they weren't honest about what was free and what wasn't. I know this
because I was annoyed with it at the time and actively looked at how they
presented themselves.

On the topic of revocation, you're missing a couple of aspects:

\- First, both end users and CAs are required to revoke certificates that are
compromised; it's not an option. It's a fundamental part of a CA's operation.

\- Second, CAs provide revocation services like OCSP for revoked and non-
revoked certificates alike. So, certainly the costs for running OCSP are
comparable in both cases. You could argue that CRLs cost a bit more, but
largely only because of the bandwidth cost (as CRL is just a file).

~~~
xoa
> _which is that they weren 't honest about what was free and what wasn't._

You have repeatedly stated this, and it is objectively false. The StartSSL
site did not forbid archiving, and thus is available [1] going back to 2004 on
the Wayback Machine. This includes both the HTML FAQ page and the policy PDFs
of the time. This isn't some EULA boilerplate, actual clear policies and
procedures for a CA you're interested in using for your infrastructure is
something that is absolutely your responsibility to read.

When discussing Revocation (clearly titled) in the FAQ and Policy & Practice
statements, even very old versions stated that a fee could be charged, and
that revocation was considered a separate issue for free usage due to growth
of the CRL. Later (since at least mid-2010, which is 2 years before Heartbleed
was even introduced and 4 years before public disclosure) made this even more
explicit, put it right in the FAQ, and put a clear price on it. From the FAQ,
2010 [2], _the first sentence_ :

>>" _72) Revocations carry a handling fee of currently US$ 24.90. [...]
Extended Validation certificates are exempt from the revocation handling fee._
"

Please explain how they "weren't honest about what was free and what wasn't."
Did you "actively look at how they presented themselves" but fail to so much
as glance at the FAQ or Policies documents in doing so? None of this was
remotely hidden, it was literally listed twice on the front page, both in the
major navigation on the top and as one of just 10 sidebar items.

> _First, both end users and CAs are required to revoke certificates that are
> compromised_

Please back up your arguments on this. WRT to end users, under what authority
at all are they "required" to do jack shit? Failing to do so in SOME
industries and jurisdictions MIGHT involve negligence, but even that would
depend on what other measures are taken. Please link any specific legislative
or regulatory authority requirements to the contrary.

As far as CAs themselves, the authority would be the CA/B (enforced by virtue
of browser/OS inclusion requirements, so the real ultimate "authority" there
would be Apple/Google/Microsoft/Mozilla/OSS major distros & projects). At the
time when StartCom established its initial policy, v1 of the CA/B baseline
requirements [3] had not even been adopted yet (BR v1 adoption was Nov 2011,
effective date was July 2012). Even then, 13.1.1 merely stated that:

>> _" 13.1.1 REVOCATION REQUEST: The CA SHALL provide a process for
Subscribers to request revocation of their own Certificates. The process MUST
be described in the CA’s Certificate Policy or Certification Practice
Statement. The CA SHALL maintain a continuous 24x7 ability to accept and
respond to revocation requests and related inquiries."_

There were reporting requirements, and a 13.1.5 covers circumstances under
which a CA must revoke within 24 hours. The most recent version, BR 1.4.5
(1.4.6 & 1.4.7 are in review), moves revocation to section 4.9 and includes
additional details and sections (including, note, that there is no maximum
latency on CRLs stipulated so a dishonest CA could make them "free" but run it
off a toaster that takes 20 minutes per request).

However in none of this is it required that the CA make the process available
for arbitrary usage at no cost. If a subscriber refuses to pay and the CA
discovers a cert falls under one or more SHALL REVOKE parts of "Reasons for
Revoking a Subscriber Certificate", then they have to revoke anyway and the
cost may be unrecoverable, but they are free to treat it as a debt and go
after the purchaser on their own for that money (or ban them from further use
of their services). StartCom had a written laid out policy and procedure, and
it was available continuously on their site. What requirement did they fail
at?

> _Second, CAs provide revocation services like OCSP for revoked and non-
> revoked certificates alike. So, certainly the costs for running OCSP are
> comparable in both cases. You could argue that CRLs cost a bit more, but
> largely only because of the bandwidth cost (as CRL is just a file)._

Note again (and I pointed at this in my original reply): even now, BR contains
no requirements on specific availability or latency beyond the original
requirement (13.2.3 v1.0, 4.10.2 v1.4.5) that:

>>" _The CA SHALL operate and maintain its CRL and OCSP capability with
resources sufficient to provide a response time of ten seconds or less under
normal operating conditions._ "

Ten seconds! Under _normal operating conditions_ (DDOS survivability, ha!).
Meeting requirements on the cheap is not the same as doing it right (to the
extent that's even possible). And you are far to blasé about the growth of CRL
in a situation where an unlimited number of 1 or 2 year length certs can be
issued free of charge. One of the most principle rules of service scaling is
that if you make something available that has a minor cost available at no
cost, there is always a risk that users will fully take advantage of that.

One of the best parts about the new BRs is that they've started the process of
allowing CAs to replace base OCSP requirements with use of Stapling (although
oddly only for "high traffic" sites, whatever that means). That should be
generalized/accelerated and both CRLs and base OCSP done away with entirely
ASAP. But even given previous and existing rules I find your assertions that
StartCom was dishonest or failed to meet requirements unconvincing right now.

\----

1:
[http://web.archive.org/web/*/www.startssl.com](http://web.archive.org/web/*/www.startssl.com)

2:
[http://web.archive.org/web/20100704102024/http://www.startss...](http://web.archive.org/web/20100704102024/http://www.startssl.com:80/?app=25#72)

3: [https://cabforum.org/baseline-requirements-
documents/](https://cabforum.org/baseline-requirements-documents/)

~~~
ivanr
I've already explained in one of my earlier posts in this very thread: In my
opinion, it was dishonest to advertise certificates as "100% free" when they
charged for revocation.

Just because the revocation charges were documented somewhere on the web site
doesn't make it right. A large percentage of certificates is revoked.
Revocation is a normal and expected part of certificate lifecycle. Thus they
should have been crystal clear upfront saying "we charge for revocation" in
the same sentence where they said "we don't charge for issuance". They could
have mentioned it on the same page, but they didn't do that either (I just
checked their "free" certificate page from a random point in time.) So ask
yourself why they didn't put such an important fact where most people would
see it.

------
fenwick67
They are trying to crawl back:

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

------
brian_herman
Is there a tool that we can use to tell if we have these certs?

~~~
dom0

        echo | openssl s_client -connect somewhere.net:443 -servername somewhere.net | grep -qE "(WoSign)|(StartCom)"

~~~
ivanr
That's a bit simplistic. For example, you at the very least want to have a
"-servername" there to account for SNI-only hosts. You'll then need to worry
about prefixed and non-prefixed hosts (e.g., www.example.com and example.com).
Then, what do you do if your web site relies on a third-party sites that uses
WoSign? Yes, now you have to parse the HTML response, extract all links, and
check those too.

Then there's also a question of servers other than HTTP, so you need to throw
in a port scanner in there. And a tool to actively follow protocols, to
discover MX hosts, maybe even look at SRV records, and so on.

------
microcolonel
I fully encourage you folks to prune your trusted CAs. I personally whitelist
only some CAs. I keep a separate root for visiting Chinese websites like Baidu
Wenku.

~~~
walrus01
it is frankly astonishing how many browsers/OS platforms ship by default
trusting all of the major mainland chinese root CAs.

~~~
Tinyyy
It’s astonishing because somehow the Chinese deserve to be treated differently
from everyone else?

~~~
walrus01
Because the Chinese government has a well documented track record of
attempting to MITM SSL, and if your system trust the root CA... game over.

[https://www.google.com/search?q=china+ssl+mitm&ie=utf-8&oe=u...](https://www.google.com/search?q=china+ssl+mitm&ie=utf-8&oe=utf-8)

------
walrus01
Should have happened eight months ago. I can understand the careful and
deliberative process behind the "CA death penalty" from a major browser, but
this was such an egregious case that I think faster action was warranted.

------
danjoc
And yet, on my brand new Android Nougat phone, I have these StartCom and
WoSign CAs. I just disabled them, but I doubt many users will.

~~~
ElijahLynn
Thanks, just did this on my Pixel.

------
snakeanus
I had hopped that they would do that much earlier. WoSign and StartCom acting
in a shady way has been known for quite a long time.

~~~
michaelt
Where can one learn what CAs are acting in a shady way? Are there other CAs on
a similar course?

~~~
snakeanus
I would say that Comodo is quite shady, sadly it seems that cloudflare sites
use it so getting rid of it would be quite difficult.

They make multiple low quality and mostly useless applications - one could
even call them scamware:
[https://en.wikipedia.org/wiki/Comodo_Group#Consumer_Security...](https://en.wikipedia.org/wiki/Comodo_Group#Consumer_Security_Products).
They also forked Chromium and Firefox and made their own rebranded browsers
which offer nothing of value.

They have multiple clearly fake comments on their certificate pages:
[https://ssl.comodo.com/comodo-ssl-
certificate.php](https://ssl.comodo.com/comodo-ssl-certificate.php) and
[https://ssl.comodo.com/wildcard-ssl-
certificates.php](https://ssl.comodo.com/wildcard-ssl-certificates.php)

And finally they tried to trademark the name of LE:
[https://en.wikipedia.org/wiki/Comodo_Group#Let.27s_Encrypt_t...](https://en.wikipedia.org/wiki/Comodo_Group#Let.27s_Encrypt_trademark_registration_application)

------
bsou
question for the knowledgeable: I've used AWS's ACM for my certs so far, are
there any big reasons why I should be using LE instead?

~~~
ivanr
No. Quite the opposite, AWS automates certificate issuance for you. You'd have
to automate the process yourself if you switched to LE.

Of course, AWS only issues certificates when you're using their stuff. For
everything else, use LE :)

~~~
toomuchtodo
Nitpick: You can only use ACM with ELBs/ALBs/Cloudfront Distributions.

