Though I'm not a GlobalSign customer, I'm told that GlobalSign sent the
following email to its partner ecosystem:

Dear Partner,

In reaction to current events related to the private key exposure and mass
revocation by Trustico/Digicert, GlobalSign is reaching out to its trusted
Partners and Resellers to survey how they approach customer private key and
CSR generation. The most secure method is to generate the keys on the
server and then use the CSR when requesting the certificate. If you do
generate private keys for any of your customers outside of the web server
environment where the certificate will be hosted, we request that you stop
this practice immediately.

We ask that all Partners and Resellers complete the following short
questionnaire as soon as possible or by: Friday, March 16, 2018.

Compliance questionnaire : [REDACTED]
Note: Only one questionnaire needs to be completed per company.

Thank you in advance for your cooperation and attention to this important
topic.

Kind regards,
GlobalSign Security and Compliance


So it's nice to see that at least one CA is taking action on this topic
without being ordered to (that I'm aware of). Obviously not all resellers
are like Trustico and perform only a straight certificate pass-through, as
Ryan Sleevi pointed out, and key escrow is a necessary part of acting as a
host, or CDN, or other authorized representative.

But surely there is still some way to responsibly look through the
ecosystem for resellers that do not perform an authorized function that
requires key escrow. Are any other CAs willing to do something like
GlobalSign has done?

Also, it would be very helpful if GlobalSign could share some information
relating to the responses they get, even if they are aggregated or
anonymized.

-- Eric

On Sun, Mar 4, 2018 at 4:04 PM, Eric Mill <e...@konklone.com> wrote:

> Last week, Trustico (a reseller, formerly for Symantec and now for Comodo)
> sent 23,000 private keys to DigiCert, to force their revocation. This
> showed that Trustico had been storing customer keys generated through one
> or more CSR/key generation forms on their website.
>
> Though Trustico disagrees, this appears to be a clear case of routine key
> compromise for subscribers who obtained their key from Trustico. The
> security of Trustico's systems, which are not audited or accountable to
> root program requirements, were storing large amounts of key material whose
> compromise could have led to the subsequent compromise of connections to
> tens of thousands of online services.
>
> It was also noted that Trustico was exposing key material to interception
> by a number of third parties through client-side JavaScript embeds, and
> that Trustico's website had functionality that allowed remote code
> execution as root on one of their web servers.
>
> These m.d.s.p threads document/link to those things:
>
> * https://groups.google.com/d/topic/mozilla.dev.security.
> policy/wxX4Yv0E3Mk/discussion
> * https://groups.google.com/d/topic/mozilla.dev.security.
> policy/BLvabFwcJqo/discussion
>
> As part of the second thread, Comodo noted:
>
> We also asked Trustico to cease offering any tools to generate and/or
> retain customer private keys.  They have complied with this request and
> have confirmed that they do not intend to offer any such tools again in the
> future.
>
>
> That is good to hear, but a "we won't do it again" response, if accepted
> by Comodo as sufficient, seems disproportionate to the severity of the
> issue, given Trustico's unfamiliarity with norms around private key
> management, and with basic security practices.
>
> It's also clear from the experience that rules of the road for resellers
> are unclear, and that accountability is limited. It seems possible, or
> likely, that other resellers may also be mishandling customer keys
>
> So, what would useful next steps be to improve security and accountability
> for resellers?
>
> One thought: Mozilla could ask CAs to obtain a written response from all
> contracted resellers about if/how they interact with customer key material,
> including the level of isolation/security given their key generation
> environment (if they have one), and whether any third-party JavaScript is
> given access to generated key material.
>
> Any other ideas?
>
> Also -- Comodo noted:
>
> Trustico have also confirmed to us that they were not, and are not, in
> possession of the private keys that correspond to any of the certificates
> that they have requested for their customers through Comodo CA.
>
>
> Since there appears to have been a significant overlap period, between the
> time Trustico switched to Comodo and when Trustico was asked by Comodo to
> cease key storage practices, it's a little hard to take at face value the
> assurance that Trustico was never in possession of any Comodo keys. It
> would be nice to hear something from Comodo about whether they've verified
> this in any more detail.
>
> -- Eric
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to