Mozilla and Apple ban certification centers WoSign and StartCom


    An investigation by Mozilla showed that the Chinese certification center WoSign (of which free certificates were a number of articles on Habré ) over the past couple of years has made a glaring number of violations.

    2015


    It began with little things: Google, during the ongoing monitoring of certificates, noticed repeated issuance of certificates with identical serial numbers, which is formally a violation of standards. There were other minor deviations from the rules.

    It would seem, nothing serious. But this is already in itself - a signal to the certifying center to pay attention to what is happening and to set up verification mechanisms. However, the certificate issuance policy applied by WoSign lags behind their own practice. Policy changes were made after incidents in order to smooth back retroactively and justify the deviations.

    In addition, shortcomings were found when checking “whether the recipient of the certificate is the owner of the domain for which he is requesting the certificate”. They are not critical in themselves, they could still simplify the issuance of a certificate to attackers. For example, domain ownership verification could be performed using dynamic ports (above 50,000). Mozilla is of the opinion that the issuance of certificates should be made using only privileged ports (1024 and below). At the same time, WoSign did not log the port numbers used, therefore, the scale of the problem cannot be fully assessed.

    This was followed by serious vulnerabilities. Firstallowed the malefactor owning a subdomain to receive the certificate for all domain. The researcher who discovered this was able to obtain bogus GitHub certificates (for example, test.github.io), Microsoft, and Alibaba. WoSign knew about the vulnerability for 14 months, but did not fix it, limiting itself to revoking certificates containing "github" in the domain name. Issuance of erroneous certificates continued. The remaining problem certificates the company agrees to revoke only in the case of requests from the owners of the affected domains.

    The second vulnerability was truly epic. After successfully passing a domain ownership check, the attacker had the opportunity to add any third-party domain to the list of verified domains. Absolutely any. Already without any verification.

    As if this was not enough, WoSign secretly acquired the Israeli StartCom certification center. Moreover, when the guys from Mozilla hinted that “it’s not good to do this” (and this is putting it mildly, this concealment violates the Mozilla policy ), WoSign began to deny everything and try to prevent this information from being made public .

    When it became clear that you could not hide the sewing in the bag, the company issued a press release.by admitting to "investing in StartCom". At the same time, the sole leader of StartCom and, at the same time, the CEO of WoSign is the same person. There is also technical evidence that StartCom (at the moment) uses most of the WoSign infrastructure. It turns out to be a bit of a coincidence for companies that, as the WoSign press release says, "operate and operate independently of each other."

    2016


    The following year, WoSign began with the fact that in mid-January, retroactively released certificates SHA-1. Date “rewind” a month ago. This made it possible to avoid blocking certificates by popular browsers that agreed to accept only SHA-2 certificates in 2016, because of the increase in computing power, the SHA-1 algorithm is already losing ground and is considered insufficiently robust . The documentation of the CAB Forum is clearly regulated - since 2016, certification authorities should not issue certificates using SHA-1:

    Effective January 1, 2016, CAs Must have CA rules using the SHA-1 hash algorithm.

    Three certificates were unmasked due to the inattention of WoSign: the STC tags embedded in three of them (signed certificate timestamp) indicated mid-January 2016, which clearly indicates that certificates could not be created earlier than this deadline.

    Another 62 certificates revealed due to the fact that they were issued on Sunday. This is completely uncharacteristic for WoSign - at the weekend, employees in China do not work and certificates are not issued. There were other circumstantial evidence of forgery dates.

    In July, StartCom distinguished itself with its service StartEncrypt , launched as a response to the popular Let's Encrypt. Simply by changing one parameter of the POST request at the end of the automatic verification, it was possible to ensure that the certificate was signed not from “StartCom Class 1 DV Server CA”, but “WoSign CA Free SSL Certificate G2” or even “CA 沃 通 根 证书” (another WoSign root certificate). Some of these certificates, issued by StartCom and signed by “WoSign CA Free SSL Certificate G2”, are also dated backdating.

    Formally, backdating is not prohibited, but this is a vicious practice. WoSign strongly denied that falsified the release date of these certificates. Its representatives claimed that by that time the corresponding code had been removed from the “combat” servers, which had falsified the date. But how then were the guys from StartCom able to use the code that even WoSign itself had already stopped using?

    In general, this episode demonstrates the carelessness of programmers - if in such an important process as issuing certificates, leaving the dangerous code, then sooner or later it will “shoot”. What happened.

    In addition, the question remains open, how can StartCom release a certificate on behalf of WoSign so freely? After all, WoSign CEO assured everyone that companies operate completely independently.

    Further more: StartEncrypt discovered critical vulnerabilities. One allowed as a confirmation of control over the domain to specify the path to any existing file. For example, upload a file to Dropbox and specify the path to it. The result would be a certificate release for dropbox.com. With another vulnerability, an attacker could get a certificate for any site that supports OAuth 2.0 (google.com, facebook.com, paypal.com, linkedin.com, login.live.com).

    And finally, in September 2016, someone from the community noticed that in the screenshot attached to one of the WoSign reports, the output of the dig utility from the bind-utils package appeared. The version of this utility is 9.7.3-8.P3.el6. "El6" means "Red Hat Enterprise Linux 6". Of course, RHEL6 support ends only in 2016, but here is the current version of bind-utils in it - 9.8.2-0.47.rc1.el6. And "9.7.3-8.P3.el6" corresponds to the non-updated package straight from 2011. In these five years, 19 vulnerabilities have been closed in the upstream. Let none of them be critical, you involuntarily ask yourself a question - maybe in WoSign for so many years have not bothered to update not only one server, but the entire infrastructure?

    And what is the result?


    Moziila decided for a year to stop trusting new WoSign and StartCom certificates. Issued earlier, good or bad, remain in force. For the released year, the certification centers must correct all the shortcomings, and then undergo a series of checks. Otherwise, their certificates will be blocked forever.

    Apple Inc., after reviewing the report, announced that iOS and macOS indefinitely cease to trust certificates issued after September 19, 2016. Since Apple's WoSign root certificates are not preinstalled, the intermediate certificates from StartCom and Comodo used by WoSign will be banned.

    The reaction of the other major players in the browser market (Google and Microsoft) is still unknown.

    Update as of October 10, 2016 : The Chinese company Qihoo 360, which owns both certification centers, agreed to completely separate WoSign and StartCom, and then pass all the required checks. In addition, the head of WoSign was removed from office.

    Update as of October 26 , 2016 : Beginning with Firefox 51, certificates issued by WoSign and StartCom after October 21, 2016 will be considered invalid. Certificates using SHA-1 and backdated are revoked via CRL. The root certificates WoSign and StartCom with which the violations were implemented will be deleted in the future. Certifying centers will have to issue new root certificates. If Mozilla agrees to accept these new root certificates, then their inclusion is just due to the removal of old ones. And if you do not agree, the old certificates will still be deleted after March 2017. As for the audit firm “Ernst & Young Hong Kong”, which missed the violations of WoSign, their audits are no longer credible.

    Update as of November 1 , 2016 : Chrome 56 will mark certificates issued by WoSign and StartCom after October 21, 2016, as not trustworthy .

    Update as of July 8, 2017: Starting from Chrome 61,trust completely ceases to all WoSign and StartCom certificates , even those issued before October 21, 2016.

    Update as of August 9, 2017: Microsoft also ceases to trust the certificates of these certification authorities . Windows will continue to trust only certificates issued earlier September 26, 2017.

    Update as of August 9, 2017 : StartCom management decided to close the company.
    Text of the letter
    Dear customer,

    As you are surely aware, the browser makers distrusted StartCom around a year ago and therefore all the end entity certificates newly issued by StartCom are not trusted by default in browsers.

    The browsers imposed some conditions in order for the certificates to be re-accepted. While StartCom believes that these conditions have been met, it appears there are still certain difficulties forthcoming. Considering this situation, the owners of StartCom have decided to terminate the company as a Certification Authority as mentioned in Startcom´s website.

    StartCom will stop issuing new certificates starting from January 1st, 2018 and will provide only CRL and OCSP services for two more years.

    StartCom would like to thank you for your support during this difficult time.

    StartCom is contacting some other CAs to provide you with the certificates needed. In case you don´t want us to provide you an alternative, please, contact us at certmaster@startcomca.com

    Please let us know if you need any further assistance with the transition process. We deeply apologize for any inconveniences that this may cause.

    Best regards,

    StartCom Certification Authority

    Also popular now: