Keys

Trustico, a reseller of SSL certificates, has stated that they stored the private keys of some of the SSL certificates it issued to its customers over the past years. This came in the form of a statement Trutico posted on its website late last night.

Prior to the announcement, DigiCert and several security researchers implied that Trustico might have broken industry standards and the client-CA trust relationship by storing private keys for the SSL certificates it helped broker.

Only customers (site owners) should have access to a SSL certificate's private key. This is because anyone with a copy of the private key can impersonate a site's HTTPS connection or decrypt logged or real-time traffic meant for that site.

There is no evidence that Trustico ever abused these private keys. The common belief is that Trustico logged the private keys via a tool it offered on its site to automate the SSL certificate issuance process.

Trustico's decision to email customer's private keys

Trustico published its statement as part of an argument with DigiCert. A timeline of events is available in our previous coverage here.

To put the story short, Trustico wanted to move all its customers from Symantec's soon-to-be-distrusted infrastructure to Comodo certificates. It asked DigiCert —now in charge of Symantec's old SSL infrastructure— to mass-revoke 50,000 certificates. DigiCert declined, saying that only end-customers, and not the reseller, can initiate a revocation.

DigiCert said the only way Trustico would be able to mass-revoke so many certificates without client approval would be if the certificates were compromised. Trustico then sent the private keys of over 23,000 customers via email to DigiCert —effectively compromising the security and privacy of those certificates, triggering yesterday's mass-revocation.

Trustico faces backlash

The move to email the private keys of its customers to DigiCert so it could move customers to a new Certificate Authority's (CA) infrastructure has not gone over well with the CA community.

"To arrive at the conclusion that Trustico have been anything other than grossly negligent here is rather difficult," said Scott Helme, an information security consultant and an expert in the CA domain.

"Generation, storage and the apparent ease and willingness to further compromise the keys are all outrageously inappropriate," he added. "They could have trivially proven ownership of those keys without the need to zip 24k+ of them and send them via email. If these actions were motivated by business/politics as some suggest, it'd be ironic if their actions resulted in their removal as a reseller."

DigiCert reported the revocation incident on the Mozilla security mailing list, which is often used to discuss affairs of the CA/Browser Forum, the organization that sets and enforces the rules of the SSL/HTTPS industry. Members of this mailing list had concerns regarding Trustico's access to the private keys.

"Trustico doesn't seem to provide any hosting or CDN services that would make use of the private key, nor do they appear to explicitly inform users about the storage of this private key," said Eric Mill, Senior Advisor at the U.S. General Services Administration's Technology Transformation Service, hinting that there was no apparent reason for Trustico to keep copies of the private keys.

"The storage of private keys appears to be done without the user's knowledge or consent," he added. "Given everything that's known, then regardless of who emailed whose customers when and why, I think it's clear that Trustico compromised those keys [...], and has been routinely compromising customer keys for years."

"Given that there's no evidence that Trustico [...] indicated any intent to change their business practices, then I believe it's appropriate for all CAs to immediately suspend or terminate their relationship with Trustico," Mill added.

Expert explains how Trustico apparently logged private keys

Mill also gets into the details of how Trustico apparently compromised everyone's private keys:

In their statement, they say they keep the private keys explicitly to perform revocation as necessary:
https://www.trustico.com/news/2018/symantec-revocation/certificate-replacement.php (archived: https://archive.is/0AnyR )

> These Private Keys are stored in cold storage, for the purpose of revocation.

Their CSR/key generation form is here: https://www.trustico.com/ssltools/create/csr-pem/create-a-new-csr-instantly.php
(archived: https://archive.is/hJV42 )

The storage of private keys appears to be done without the user's knowledge or consent. And of course, only the keys they create through their form are stored, so it is clearly not a necessary business function for most of their certificate business.

Finally -- the CSR/key generation form page incorporates JavaScript from at least 5 or 6 different companies (including ad servers), which would allow any of those third parties (intentionally or through compromise of their own) to capture generated keys. This is a reckless amount of exposure, to the point that even if the keys were generated completely inside the browser and never exposed to the server (which does not appear to be the case), I would consider them compromised at the time of generation.

Security researcher Kevin Beaumont has been looking through the list of compromised certificates and discovered that some of these certificates were being used by organization's that require high security.

Beaumont says he found private keys for SSL certificates that were used to secure banking email servers just by looking at ten of the 23K now-revoked certificates.

In the end, Trustico is entitled and had the contractual right to change its SSL certificates reselling partner from DigiCert to Comodo due to Symantec's past security issues. The main concern among the community is how they went about doing it.

Sending private keys and causing thousands of clients to reconfigure their sites, which may have caused business losses, may not have been a good idea.

Related Articles:

Starting Today, Google Chrome Will Show Warnings for Non-Logged SSL Certificates

Google's .App Domains With Baked-In HTTPS Are Now Open for General Registration

Mac Security Tool Bugs Allow Malware to Appear as Apple Software

Google Chrome to Remove “Secure” Indicator From HTTPS Pages in September

Facebook's Phishing Detection Tool Now Recognizes Homograph Attacks