Microsoft Dumps Notorious Chinese Secure Certificate Vendor (zdnet.com)

Soon, neither Internet Explorer nor Edge will recognize new security certificates from Chinese Certificate Authorities WoSign and its subsidiary StartCom. ZDNet reports: A CA is a trusted entity that issues X.509 digital certificates that verify a digital entity's identity on the internet. Certificates include its owner's public key and name, the certificate's expiration date, encryption method, and other information about the public key owner. Typically, these are used to secure websites with the https protocol, lock down internet communications with Secure Sockets Layer and Transport Layer Security (SSL/TLS), and secure virtual private networks (VPNs). A corrupted certificate is barely better than no protection at all. It can be used to easily hack websites and "private" internet communications.

Microsoft has joined [Mozilla, Google and Apple] in abandoning trust in their certificates. A Microsoft representative wrote: "Microsoft has concluded that the Chinese CAs WoSign and StartCom have failed to maintain the standards required by our Trusted Root Program. Observed unacceptable security practices include back-dating SHA-1 certificates, mis-issuances of certificates, accidental certificate revocation, duplicate certificate serial numbers, and multiple CAB Forum Baseline Requirements (BR) [issuance and management rules for public certificates] violations." Microsoft will start "the natural deprecation of WoSign and StartCom certificates by setting a 'NotBefore' date of 26 September 2017. This means all existing certificates will continue to function until they self-expire. Windows 10 will not trust any new certificates from these CAs after September 2017."

Comments

Only mousetraps offer free cheese

[Tablizer]

Unfortunately, both CAs had large installed user bases, largely because both had offered free certificates. [Emph. added]

If it sounds too good to be true, it probably is.

Re:Only mousetraps offer free cheese

[Otter87]

Unfortunately, both CAs had large installed user bases, largely because both had offered free certificates. [Emph. added]

If it sounds too good to be true, it probably is.

So "letsencrypt" is too good to be true as well ?

Re: Only mousetraps offer free cheese

[Anonymous Coward]

No, Letsencrypt is just bad, in my opinion. Certs expiring after just a few months sucks. I know, I know, cert renewals are supposedly 'automated'. But that's only true when this automation doesn't break, and it broke for some reason when I tried it. I just bought a year-long cert instead from another vendor. It was well worth paying to not have to deal with Letsencrypt.

Re:Only mousetraps offer free cheese

[Billly Gates]

It is. I read here system administrators ban then from their networks due to them allowing anyone to buy a cert with phisy websites.

Re: Only mousetraps offer free cheese

[Ash-Fox]

But that's only true when this automation doesn't break, and it broke for some reason when I tried it.

Wow, considering how brain dead the system is... It makes me not want to visit a website operated by you.

Re: Only mousetraps offer free cheese

[higuita]

letsencrypt is not 100% free... you are required to use your time to setup the automation... if your time is more expensive than buying a normal certificate, go for it... if not, adding a cron and email notification when the script fails is probably "cheaper".

It is your server, your decision

Re: Only mousetraps offer free cheese

[DarkOx]

Let's Encrypt is bad for a whole host of other reasons. They don't even do real domain verification at least not when I looked. You only had to have access to the host. What's more likely? Compromise a 3rd party DNS provider, or compromise someones terrible website? As far as access to the host goes you might not even need much access to the host, a simple path traversal bug that lets you write inside the wwwroot would be enough. You don't even need to full pwn it, likely.

The bigger issue though is LE is entirely robotic, they will sign anything even if its an obvious phishing domain, something like 1300 fake paypal certs went out, for sites like paypall etc. Sure that is somewhat the users fault for not carefully checking urls but considering everything is corss-domain-ajax request these days...

LE has essentially destroyed what little faith in authenticity one could still have in the CA system as far as their certs go. Honestly for a security perspective THEY MIGHT AS WELL BE SELF SIGNED. All LE certs should be treated exactly as one would treat a self signed cert.

Re: Only mousetraps offer free cheese

[badzilla]

Letsencrypt sounded great but broke on installation for me. Broke (differently) for a work colleague also. When your product majors on ease of use then this is not good, not good at all. OK it's free, thank you, but especially as it rather bizarrely wants unusually frequent cert renewal why take the risk of it eating all your support time?

Re: Only mousetraps offer free cheese

[Ash-Fox]

Letsencrypt sounded great but broke on installation for me.

I've done installations across RHEL, CentOS, SuSE, Ubuntu, Debian, Slackware (and on Slack I had to do it manually, which was trivial), OpenBSD and Windows. I don't think I've ever encountered a situation where it "broke on installation". I almost get the impression you used the wrong version for the wrong distro version or something else equally absurd?

why take the risk of it eating all your support time?

Generally, whatever goes into production is well tested on my end and I have contingency plans setup where there are failures I might expect. No major risks on my end typically?

Re: Only mousetraps offer free cheese

[realxmp]

I agree HTTP challenges leave much to be desired but DNS based challenges aren't really much better. The scenario where someone compromises your DNS provider and can both answer a DNS based challenge and redirect traffic is equally as nasty and not as unlikely as you suggest. The more likely scenario is still a similar domain name attack anyway, as it's a lot easier to do. If you're compromised you need to check certificate transparency records for that domain and force a revoke, use CAA, and key pinning.

It is likely most certificate authorities will adopt ACME soon, it will probably become pretty much ubiquitous for domain validated certificates. Other CA's have issued phishing certs, the reason why LE is being used is because it doesn't cost rather than because they're the only automated shop out there. I would argue that any trust that LE may have destroyed shouldn't have been there in the first place anyway. Certificate authorities should concern themselves with organisation validated or extended validated certificates only and DV should only be treated as verified at the DNS level as that's the only way to solve the problem in real time.

Re: Only mousetraps offer free cheese

[JohnFen]

Certs expiring after just a few months sucks.

And it sucks hard, even when the automation does work. That's why I avoid Let's Encrypt -- it's just not for me. That said, it's probably fine for most people.

NotAfter

[Anonymous Coward]

Setting NotBefore will expire all current certificates and allow WoSign and StartCom to issue certificates that will be trusted in the future. Setting NotAfter will no longer trust these certs in the future. Hopefully, the Microsoft engineers are more attentive than ZDNet writers and editors.

Re:NotAfter

[skids]

Either will allow them to issue new certificates since:

Observed unacceptable security practices include back-dating SHA-1 certificates

...one could argue they did this to work around some SHA-1 retirement quirk, but it is only a shade of difference for them to resort to back-dating anything. Of course, if they get caught doing that, store maintainers could escalate to just removing their root entirely. Which they may or may not care about depending on the legal system over there.

Re:NotAfter

[thsths]

They did get caught for it, so why should we trust them not to do it in the future?

Work done, no need to continue

[whoever57]

Wosign's work is clearly done now and presumably the Chinese government will move on to another certificate vendor.

Wait... What?

[Anonymous Coward]

Observed unacceptable security practices include back-dating SHA-1 certificates

Windows 10 will not trust any new certificates from these CAs after September 2017.

So what's to prevent them from back dating new certificates?

Re:Wait... What?

[Nkwe]

So what's to prevent them from back dating new certificates?

Removal of the CA's root certificate from the browser's (operating system's in the case of IE) list of trusted root authorities would do it, but it sounds like they are not doing that yet.

Sounds like Microsoft is playing nice and not yanking the root cert now, instead they are creating a soft landing where they will not honor new certs (with the assumption that new backdated certs won't be created.) In a year when all of the certs would have expired anyway, the root cert would be removed.

Personally I would have just yanked the root cert at the first sign of weirdness from the CA. After all we are only talking about the default list of trusted roots, users can add their own if they feel the need to trust something untrustworthy.

Re:Wait... What?

[freeze128]

They should do that now.

If I may quote Vilos Cohaagen (Ronny Cox) from 1990's Total Recall:

"Fuck 'em. It'll be a lesson to the others."

Re:Wait... What?

[Shimbo]

So what's to prevent them from back dating new certificates?

They've been caught once. It wouldn't be hard to run a query against the EFF SSL Observatory (or similar) and see if there is a pattern of new certificates appearing with dates before the cutoff.

Re:Wait... What?

[DarkOx]

Agreed, they should not be adding custom code paths to handle individual CAs. That is a recipe for bugs and errors in what is supposed to be an AAA function.

If MS does anything they should add a Do-Not-Trust-After-Date option to their certificate manager for all CAs, and make this visible and settable by end users. Ideal with an additional flag "Set-by-Microsoft" to indicate its value that came down thru windows update. Their update process should never set a later date than a user has set.

Re:Wait... What?

[lachlan76]

There is a trade-off, though—if you suddenly remove a large certificate vendor, you risk training users to click through the warnings, and end up potentially worse-off than you were before. The more recent trend seems to have been to require the use of Certificate Transparency by issuers that have been caught misbehaving.

Re:Wait... What?

[JohnFen]

Personally I would have just yanked the root cert at the first sign of weirdness from the CA. After all we are only talking about the default list of trusted roots, users can add their own if they feel the need to trust something untrustworthy.

I would have done this as well. But, since most Windows users are not technically savvy, I'm sure that Microsoft took one look at the shitstorm that would hit their support desks (and the press) and flinched.

Re:Wait... What?

[JohnFen]

But the entire basis and reason for removing trust in the first place is that WoSign refuses to follow the rules set forth for CAs.

The entire basis for removing trust in the first place is that Microsoft has decided they don't trust WoSign certs. It's not some sort of "punishment" for breaking the rules.

Conversely, If Microsoft decided that a CA wasn't trustworthy but didn't yank their cert because they were technically following the rules, then Microsoft would be doing wrong.

Re:Something you can trust however

[Anonymous Coward]

I'm on it!

Question remains:

[fustakrakich]

What good is https if you can't trust the certs?

In today's world any system based on trust is just not sustainable. What we need is verification, not trust.

Re:Question remains:

[skids]

There are still benefits... not everyone who wants to p0wn you has a MITM; some can only eavesdrop. But yes, trust has obviously been spread too widely.

Re:Question remains:

[JohnFen]

Personally, I don't actually trust any cert just because a commercial CA has signed it.

Screw WoSign

[jez9999]

I used StartCom's free certs for years with no problem. First I hear of WoSign it's that they bought out StartCom and ruined it. It's a real shame, and Let's Encrypt is no alternative. I'd rather pay for a year cert than put up with a few months.

Re:Screw WoSign

[Ash-Fox]

If you setup Let's Encrypt right, it will automatically renew and install continuously without manual intervention.

Re:Screw WoSign

[Zemran]

Agreed, Let's Encrypt is better than the rest and free. How could anything be better?

Must use NSA-compromised CAs!

[gweihir]

Quite frankly, that probably means that WoSign was unwilling to issue faked certificates for the NSA or that they failed to hack it. Sure, it _will_ issue faked certificates for the Chinese Government, but the security arguments cited are nonsense. Various saboteurs (a strong contributor the US) have ensured that "official" certificates are worthless.

So, the 10 people still using IE will care...

[Zemran]

... but not the rest of us.

Re:A CA cert bundle with only first-world CA certs

[JohnFen]

I don't want to trust any CA outside of those regions, and perhaps even some within those regions.

Your assumption that CAs can be considered trustworthy by default simply because they're in countries you like is charming. Dangerous, but charming.

Until the CA starts falsifying NotBefore dates.

[mysidia]

Windows 10 will not trust any new certificates from these CAs after September 2017."

Seriously.... you're going to rely on the CA's NotBefore date to decide to invalidate the cert?
Did you forget that this CA doesn't participate in certificate transparency AND NotBefore date can
technically be set to whatever the CA wants?

The so-called "Backdating certificates" issue, Although in reality, the NotBefore date is not an issuance date;
it's a date before which the certificate should be treated as an invalid credential.

When you have an object with authenticated timestamp such as signed code, this distinction could be important,
but certificates valid only for TLS aren't used for such, so usually NotBefore is the time of issuance; however,
no guarantees.

Certainly no technical restraint on the CA.....