Root Programs Still Deciding the Fate of WoSign
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 4.67 out of 5)
Loading...

Root Programs Still Deciding the Fate of WoSign

Apple has decided to untrust a WoSign certificate

It may be hard to believe, but the WoSign/StartCom saga is still ongoing.

If you have not been following the story up to this point, here is a very quick summary: In August, WoSign, a Chinse CA, was found to have violated a series of industry standards. StartCom, an Israeli CA was also found to have some violations of their own. A former StartCom employee then presented evidence that StartCom had been quietly acquired by WoSign. Now the root programs, which dictate what CAs are trusted, are considering how to handle the violations.

If you are looking for more background, see our last update on WoSign’s problems.

Back-dating Certificates

Since our last update, Mozilla has published evidence that WoSign purposefully back-dated certificates so they could sign them with SHA-1 and not be detected by browsers. Back-dating refers to setting the “notBefore” field in a certificate (which tells you when a certificate was issued) to an earlier date. It is not explicitly forbidden to back-date certificates, many CAs regularly do this by a day or two to account for inconsistently set local time/date settings on computers. But, in this case, WoSign’s back-dating was a major violation.

SSL certificates use cryptographic signatures to allow computers to prove if a certificate is authentic. SHA-1 was the primary hashing algorithm used for these signatures until the end of last year when overwhelming evidence showed that it was a security risk. SHA-1 has since been forbidden by industry requirements and replaced with SHA-2. However, some industries have had a hard time with the transition due to a lack of SHA-2 support in certain software/hardware.

As a result, a special application has been developed that allows those who need a SHA-1 certificate to get one, albeit through a labor-intensive process. However, it looks like WoSign opted for an easier route for their customers, and tried to secretly violate industry standards.

Through careful analysis and Certificate Transparency data, Mozilla found that WoSign may have issued up to 64 certificates during 2016 which were signed with SHA-1 and backdated to appear as though they were issued in 2015.

By looking at legal incorporation documents, Mozilla has concluded that, “as of November 1st 2015, WoSign took 100% ownership of the Israel-based CA “StartCom,” through intermediary companies in the UK and Hong Kong.”

Mozilla also documented changes in issuance practices that suggest StartCom is using WoSign’s infrastructure.

As a result, Mozilla is planning on treating both CAs as one and applying any sanctions to WoSign and StartCom equally.

Mozilla has not made a final decision on sanctions, but they have proposed to distrust the CAs for a minimum of one year. After which, the CAs could reapply under special conditions, which include a full security audit of their issuance software, and try to regain trusted status. All existing WoSign/StartCom certificates will not be affected. This will minimize the effect to users while still punishing the CA.

The 64 certificates that are suspected of being back-dated will be entirely revoked and added to their OneCRL system.

If Mozilla goes forward with this action, they will be looking at the issuance date (“notBefore”) on the certificates to decide if they should be untrusted. Because the CAs were found backdating certificates, some critics pointed out that this will not prevent further mis-issuance. However, other methods for trusting the existing certificates, such as through a whitelist, are believed to be technically infeasible due to the number of certificates.

Yesterday, Mozilla had an in-person meeting with representatives from StartCom and QiHoo, a Chinese tech firm that owns a majority stake in WoSign.  Following that meeting, Mozilla will await a public proposal from WoSign/StartCom before making its final decision.

What Will Other Root Programs Do?

Over the weekend, Apple announced that it will be dis-trusting a specific WoSign intermediate certificate. This means that Apple devices will no longer trust certificates issued from the “WoSign CA Free SSL Certificate G2” certificate.

Most CAs maintain a number of roots and intermediates dedicated to different purposes, for instance different “classes” of certificates (DV, OV, EV) or for different types of public keys (RSA, ECC).

This WoSign intermediate is used for their free certificate program. WoSign’s free SSL certificates were specifically abused by researchers/attackers to issue certificates for Github and UCF.edu without proper authorization.

Similar to Mozilla’s proposed action, Apple will continue to trust existing WoSign certificates. Apple wrote: “To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19. They will continue to be trusted until they expire, are revoked, or are untrusted at Apple’s discretion.”

It is unclear exactly how Apple will trust existing certificates. As mentioned earlier, whitelisting existing certificates may be problematic due to the number of certificates. Other methods of checking if the certificate was CT logged will also be difficult.

However, Apple’s decision should be seen as incomplete. There is ample evidence that WoSign has mis-issued certificates from a variety of roots and intermediates. As of now, these other roots and intermediates will remain trusted (such as this certificate which Mozilla believes was back-dated and is trusted on Apple devices via a StartCom cross-sign).

It is unclear why they have limited their action to this specific intermediate certificate. They have also not made any announcement regarding actions against StartCom.

Apple’s root program is generally silent, and terse when it does say anything. So we may never know the reasoning for this. In its statement, Apple said that “as the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.”

This leaves two major root programs, Google and Microsoft, who have not made any formal announcements. Google’s team, who is extremely active and public with its decisions, will likely make a formal announcement when WoSign/StartCom have published their proposal following their meeting with Mozilla.

Until then, we wait to see exactly what fate awaits WoSign/StartCom. So far, both CAs are in serious trouble.

UPDATE: Since we originally published this post, Apple and Google have taken new action against WoSign and Startcom.

Apple has expanded their dis-trust to all StartCom and WoSign roots, which they announced on November 30th, 2016. WoSign/StartCom certificates issued before December 1st, 2016 will continue to be trusted.

Google has also decided to untrust all WoSign/StartCom certificates issued after October 21st, 2016. This behavior will apply in Chrome 56. Certificates issued before then will be trusted, but only if they comply with Chrome’s Certificate Transparency policy.

Chrome will also have a limited whitelist of certificates issued to “domains known to be customers of WoSign and StartCom.” These certificates will not need to be CT compliant. However this will only be a temporary measure, designed to give these sites time to transition to a new CA and avoid showing frequent warnings on high-traffic sites.

2 comments
  • Is this due to political and business reasons that Apple is being so lenient (so far) to a chinese company?

    The way I see it is, trust is earned, not traded.

    With the state of security being what it is in the headlines and on the ground, a “scorched earth” penalty should be imposed, revoke ALL certs, and dis-trust both Co.s for a year or more. If they realize that even the smallest infractions to the code of trust are broken, the penalties should always be 100% painful, not dealt in degrees.

  • Hi Dean,

    Apple’s Root Program is notoriously quiet. So its hard to know why they took the action they did, because all we have is their brief statement. No Apple representatives took part in any of the public discussions of this “saga.”

    I’d be surprised if it’s political pressure. Apple is so large that they likely don’t have to be sensitive to the issues of a relatively small Chinese CA.

    Apple’s decision is in-line with what most of the serious participants in the community have proposed. There were not too many people advocating a full dis-trust and revocation of WoSign/StartCom certs.

    The reason being that mass revocation is actually more of a punishment to the customers of that CA, then the CA itself. Now all those users have to go get a new SSL cert, and you may have the issue where many people are slow to figure out why their site is affected and may have to be billed by an IT guy to do the work for them.

    For web users, you also create a huge number of errors across the internet that will encourage people to ignore these types of warnings in the future.

    I do agree that trust is earned, and that CAs need adequate punishment. Its hard to say if Mozilla and Apple got it totally “right” here. Maybe they were a bit too lenient.

    But I do not think its realistic to have “100% painful” penalties for “even the smallest infractions.” If you look closely, you will see that just about EVERY CA in existence has broken minor rules. Even Let’s Encrypt, which is not even a year old yet, violated its Certificate Policy.

    Within the industry, it is generally seen as unfairly punitive and dangerous to end users to exact a punishment that is more extreme than the crime. Even the most cynical of CAs, like Google’s Ryan Sleevi who is an eagle-eye for all sorts of violations, does not think the “nuclear” response is appropriate in the majority of cases.

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *