Apple's response to the WoSign incidents | Hacker News Reader

Apple's response to the WoSign incidents

groups.google.com

133 pointsabritishguy38 comments

Couple notes for people less familiar with the Internet PKI/CA industry:

1. WoSign (who also owns StartCom) violated all sorts of industry standards. The worst of them was circumventing the SHA-1 deprecation by backdating an SSL certificate.

2. Now all the root programs (Mozilla, Apple, Microsoft, and Google) need to decide how they will react to this.

3. Mozilla proposed dis-trusting all new WoSign/StartCom certificates and giving them a chance to re-apply as a trusted CA in a year. This is only their proposed action, and they have not totally committed to it.

4. Apple has now said they will take similar action to Mozilla. Apple will block a specific intermediate certificate: "WoSign CA Free SSL Certificate G2"

But they will continue to "trust individual existing certificates" if they had been published to Certificate Transparency logs by September 19th.

While I have not personally confirmed this, my understanding is that there are other Wosign certificates that are trusted on Apple via cross-signing. So this seems like an incomplete solution - in the sense that some WoSign certificates (mainly the commercial certificates they sell, vs the ones they give away for free) will remain unaffected in anyway.

(Someone more familiar with the specifics of the Apple root store may be able to provide more clarity here)

5. Google and Microsoft have not yet committed to any action yet. Google will certainly make a detailed public announcement when they are ready.

6. Mozilla is meeting with QiHoo (a chinese tech company which owns a majority stake in WoSign). It is expected that Mozilla will make a final decision following this meeting.

> But they will continue to "trust individual existing certificates" if they had been published to Certificate Transparency logs by September 19th.

This seems even more sensible than Mozilla's existing proposal to trust the certificate notBefore date until proof of further backdated certificates.

>> But they will continue to "trust individual existing certificates" if they had been published to Certificate Transparency logs by September 19th. > This seems even more sensible than Mozilla's existing proposal to trust the certificate notBefore date until proof of further backdated certificates.

The question is how they'll actually do that. This was discussed in the moz-sec-policy-thread and people came to the rough conclusion that there are just too many wosign/startcom certificates to whitelist them in any reasonable way.

In the context of macOS, shipping out even a 75MB bundle of trusted certificates is "not significant".

Bundling it into the browser would increase the download size by a substantial percentage, but 75MB as a 'security update' distributed through the App Store is comparatively tiny versus the 1GB+ which is typical for 10.11 to 10.11.1 style updates.

I’m just curious, what standards did they violate other than circumventing SHA-1 deprecation?

A number of issues can be found here[1]. Among other things, they allowed domain validation on unprivileged ports and issued certificates for "parent" domains when subscribers were able to validate control of a subdomain (i.e. you could get a certificate for github.com by controlling user.github.com).

[1]: https://wiki.mozilla.org/CA:WoSign_Issues

For those who may not remember or may not have heard, QiHoo is the company behind the most popular scam browsers in the world: Qihoo 360 Secure. It was one of the most popular browsers in China with 28% of the market a few years ago. It used an IE logo colored green, force-uninstalled competing browsers by claiming they were unsafe, made uninstallation so difficult you'd often have to re-image the machine, breaks SSL, can expose user passwords, etc.

Remember, this is a "security" company.

It's rather fascinating: https://webdesign.tutsplus.com/articles/qihoo-360-secure-the...

Personally, I wouldn't trust anything this "security" company is connected with anywhere need my devices, software, or business.

And yet, unless you go through the effort of removing every trusted CA from your browser, you implicitly trust them because Mozilla/Google/etc. do.

And thus why the CA system is broken in a nutshell.

>And thus why the CA system is broken in a nutshell.

I wouldn't call it broken. From what I see on Linux and Windows, Chrom[e|ium] relies on the system's trusted certificates. You always have the last says on who's in and who's out.

EDIT: Just checked, the Chromium-specific trusted CAs can be revoked through its configuration interface, doesn't just rely on system certs. Important detail, but still, user has the last word.

Also accused of gaming antivirus tests http://www.pcworld.com/article/2919554/tencent-qihoo-antimal...

Also the sixth browser vendor in the CAB forum.

Ugh. September 19th is poor date to choose.

When this came up, the first thing I did was generate wildcard certs for our StartCom domains, as Mozilla is going to stop trusting things at some point.

But that was on ~26th September.

Choosing the 19th is giving existing customers of StartCom no chance to manage the problem in a sensible way. :(

    When this came up, the first thing I did was generate wildcard certs for our StartCom domains

A vendor you used comes under scrutiny so your response is to double down on them? Did you have prepaid credits or something? It seems like that would have been a opportune time to migrate away from them since you'd have to redeploy certs anyways.

With StartCom, once you've gone through the personal verification procedure you don't need to pay more money for new certs, nor wildcard ones.

So, no "doubling down" involved. Just a desire to have actually working certs before Mozilla's "to be announced" cut off date happens.

And then Apple comes along and (unless I'm misunderstanding) all of our certs will be useless. :(

You should get a refund from your cert provider.

> So, no "doubling down" involved

Continuing to use a CA that has a recognised history of fucking abysmal security and wilfully deceptive actions, whether you're paying money or not, is still "doubling down" IMO.

If you're getting a wildcard cert, you aren't getting EV, so why not just make the switch to LetsEncrypt?

That seems like an odd move, doubling down on the CA after news of them doing shady stuff? Why not take that opportunity to switch to something else like let's encrypt?

Really not sure why you'd think this is "doubling down"?

We've already gone through the StartCom verification process, but had only generated a few specific cert's for subdomains.

However, we're right now in the process of launching a new online project. No idea what subdomains will be needed in very near future.

It costs us no extra to generate wildcard ones, which obviously is the right move to do as they'll be valid while StartCom's new ones are no longer trusted (when Mozilla stops accepting new certs).

There's literally no way we could afford to pay for new certs from an alternative registrar instead.

> There's literally no way we could afford to pay for new certs from an alternative registrar instead.

If ~$100 is that much for you (as a company of some sort) why don't you use Letsencrypt?

Good point, that might be the better solution for the public HTTPS part of things.

Lets Encrypt doesn't provide MS Authenticode signing certs (eg to validate our downloads are legit) though. Hopefully this whole mess doesn't scope creep to include those too.

You bet it will. If MS does not revoke them, it will reflect very badly on the security of their program.

If anything, I'd expect code signing certificates to be at more risk. Usage of these certificates is inherently much more difficult to track, as signed executables are much harder to discover than web servers. As such, even if there were a "certificate transparency" process for code signing certificates (which I don't believe there is), it'd be difficult to prove it was being operated honestly.

This announcement only pertains to the "WoSign CA Free SSL Certificate G2" intermediate CA and does not affect any StartCom-issued certificates.

They might announce similar steps for StartCom in the future, but nothing as of yet.

Thanks. Glad I misunderstood it. :)

Hopefully if it expands to include StartCom certs, they use a later date.

Previously on HN, Mozilla's response to WoSign (also a good summary of what they'd done wrong): https://news.ycombinator.com/item?id=12582534

That should serve as a clear warning to other certificate authorities. Behave or you will be ruined. For most CAs having either Apple, Mozilla, Microsoft or Google remove your root certificate will drive customers away to the point where you might as well close up shop.

nobody has been ruined just yet. and when i look at how sheepishly slow mozilla reacts my guess is nobody will ever really get thrown out of that club.

what they've done is clear. it's been misconduct as a ca. untrust them. done. fuck you.

Representatives of Google, Apple, and Mozilla have all dismissed the suitability of a fast reactionary nuclear approach.

There are plenty of innocent sites who use WoSign/Startcom certificates.

It's easy to be flippant when you're not actually responsible for a browser which users use, and need to worry about adverse side-effects. You kill WoSign overnight and you now have millions of users habituated to ignoring TLS errors, and now know how to override internal browser security settings.

Hope it was worth it.

I came across this: https://support.apple.com/en-us/HT204132 earlier today.

Sorry if this is obvious to others, but just to be clear ...

As it's widely reported that WoSign has taken over StartCom's infrastructure, this implies that StartCom StartSSL Free certificates going forward won't be trusted by Apple either, correct?

It also sounds a little strange to only call out the free certificates. Are they going to allow new paid OV/EV (and what they call 'IV') certificates to remain valid?

My read on the announcement is that they won't be taking action against the StartCom CA & intermediates at this time.

The WoSign existing-certs exemption probably involves a whitelist they're shipping along with the OS. A lot of the feasibility discussions on this approach have centered on the size of the required whitelist [1]. Taking the same approach with StartCom may not be possible due to the scale. Also, StartCom certificates don't have the same coverage in the Certificate Transparency logs - so the certificate dating is problematic.

Hmmm, thinking about this now, if I were Wosign, I would be having a fire sale on StartCom. Selling the brand immediately (maybe to an existing competent CA) and asking the trust store operators for understanding (probably conditioned on full CT reporting) might be a way to recoup some losses out of all this mess.

Representatives of Qihoo 360, StartCom, and Mozilla are meeting in London next week. I'm very curious what they will be discussing. [2]

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/... [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/...

There are plenty of other ways to get a free certificate, e.g.

Let's Encrypt

AWS Certificate Manager

cPanel's AutoSSL

CloudFlare

Symantec Encryption Everywhere

Not to mention the certificates that can be bought very cheaply through resellers e.g. PositiveSSL.

Seems like a sensible response. I do wonder how they will know what certificates are currently signed by WoSign, as they stated that individual certificates will still be trusted somehow.

I think they're only trusting certificates that were published in transparency logs before 2016-09-19.

You can check that log at https://crt.sh

Apple will continue to trust existing certs from WoSign (provided they are CT logged). New certs will not be trusted.

mac OS will make this decision by first looking at signatures. It will receive the "end-entity" certificate (a cert for a specific site, like example.com) and while checking the chain, will see that there is a signature from the "WoSign CA Free SSL Certificate G2 intermediate CA" certificate.

It will then look at the "notBefore" date listed in the certificate, which tells you when the certificate was issued. If it is a new certificate, it will not be trusted.

If the certificate is preexisting (presumably issued before 9/19/16) it will be trusted ONLY if the certificate is CT logged. It will know if this is the case by looking for an SCT belonging to that certificate. The SCT will either be embedded directly in the certificate, or provided with the certificate during the SSL handshake (this is known as "stapling").

> If the certificate is preexisting (presumably issued before 9/19/16) it will be trusted ONLY if the certificate is CT logged. It will know if this is the case by looking for an SCT belonging to that certificate. The SCT will either be embedded directly in the certificate, or provided with the certificate during the SSL handshake (this is known as "stapling").

I doubt they'll do it this way. WoSign has only been embedding SCTs for all certificates since July and I wouldn't count on many webservers implementing SCT stapling. I expect Apple to ship a whitelist of hashes of certs that should be trusted instead.

Interesting that Apple's root program is effectively anonymous– sent from a group alias and signed off as a program.

The John Ringo approach, from "Citadel". A Chinese supplier cut corners on the gold plating of a contact and caused a major accident. The response:

"The supplier, Qua Tang Electronics, is blacklisted. Find every person associated, every member of the board, every senior officer, and blacklist any company they are associated with as well. With something like this, and the Chinese, there is no overkill. Be wildly unaimed in your fire. Nuke first, ask questions afterward. Make the pain as widespread as possible."

Reply on news.ycombinator.com