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.

> 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

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.