23,000 HTTPS Certs Axed After CEO Emails Private Keys (arstechnica.com) 72
An anonymous reader quotes Ars Technica:
A major dust-up on an Internet discussion forum is touching off troubling questions about the security of some browser-trusted HTTPS certificates when it revealed the CEO of a certificate reseller emailed a partner the sensitive private keys for 23,000 TLS certificates. The email was sent on Tuesday by the CEO of Trustico, a UK-based reseller of TLS certificates issued by the browser-trusted certificate authorities Comodo and, until recently, Symantec...
In communications earlier this month, Trustico notified DigiCert that 50,000 Symantec-issued certificates Trustico had resold should be mass revoked because of security concerns. When Jeremy Rowley, an executive vice president at DigiCert, asked for proof the certificates were compromised, the Trustico CEO emailed the private keys of 23,000 certificates, according to an account posted to a Mozilla security policy forum. The report produced a collective gasp among many security practitioners who said it demonstrated a shockingly cavalier treatment of the digital certificates that form one of the most basic foundations of website security... In a statement, Trustico officials said the keys were recovered from "cold storage," a term that typically refers to offline storage systems. "Trustico allows customers to generate a Certificate Signing Request and Private Key during the ordering process," the statement read. "These Private Keys are stored in cold storage, for the purpose of revocation."
"There's no indication the email was encrypted," reports Ars Technica, and the next day DigiCert sent emails to Trustico's 23,000+ customers warning that their certificates were being revoked, according to Bleeping Computer.
In a related development, Thursday Trustico's web site went offline, "shortly after a website security expert disclosed a critical vulnerability on Twitter that appeared to make it possible for outsiders to run malicious code on Trustico servers."
In communications earlier this month, Trustico notified DigiCert that 50,000 Symantec-issued certificates Trustico had resold should be mass revoked because of security concerns. When Jeremy Rowley, an executive vice president at DigiCert, asked for proof the certificates were compromised, the Trustico CEO emailed the private keys of 23,000 certificates, according to an account posted to a Mozilla security policy forum. The report produced a collective gasp among many security practitioners who said it demonstrated a shockingly cavalier treatment of the digital certificates that form one of the most basic foundations of website security... In a statement, Trustico officials said the keys were recovered from "cold storage," a term that typically refers to offline storage systems. "Trustico allows customers to generate a Certificate Signing Request and Private Key during the ordering process," the statement read. "These Private Keys are stored in cold storage, for the purpose of revocation."
"There's no indication the email was encrypted," reports Ars Technica, and the next day DigiCert sent emails to Trustico's 23,000+ customers warning that their certificates were being revoked, according to Bleeping Computer.
In a related development, Thursday Trustico's web site went offline, "shortly after a website security expert disclosed a critical vulnerability on Twitter that appeared to make it possible for outsiders to run malicious code on Trustico servers."
Bullet, Meet Foot (Score:2)
When Jeremy Rowley, an executive vice president at DigiCert, asked for proof the certificates were compromised, the Trustico CEO emailed the private keys of 23,000 certificates
Those certificates are DEFINITELY compromised now.
Re: (Score:3)
When Jeremy Rowley, an executive vice president at DigiCert, asked for proof the certificates were compromised, the Trustico CEO emailed the private keys of 23,000 certificates
Those certificates are DEFINITELY compromised now.
TFA seems to imply that he emailed the private keys in order to prove that they were compromised. Which seems like an appropriate thing to do.
Re: (Score:1)
Re: (Score:2)
No... it is NOT appropriate for a CA or a reseller of a CA to retain customers' private keys in the first place --- it is even MORESO inappropriate for a CA to deliberately extract and use in any manner for any purpose a customer's private key from "secure cold storage" without that customer's specific authorization.
Basically this changed the situation from "There are security concerns related to this certificates", to --- This CA reseller deliberately
Re: (Score:2)
I'm guessing that was the compromise Trustico was reporting. The private keys should've been deleted immediately after they were generated for the customer. But Trustico probably found during an audit that they hadn't been deleted and were still on their servers somewhere. Since they couldn't prove that those private keys hadn't been copied, they erred on the side of caution and declared them
Re: (Score:3)
The issuer should NEVER set eyes on a private key which isn't theirs. If you want to make life easier for your customer, do it client-side with JavaScript and throw a PFX at them once the issuance has completed.
It still stuns me how many in tech, even CAs, have such a poor understanding of how PKI works.
Re: (Score:2)
You do not need a private key to revoke a certificate. You need the certificate serial number.
As a reseller, they wouldn't have any legal right to revoke the certificate without customer permission -- that should be an act of the CA.
Notice how in the article that DigiCert Demanded Proof of the compromise?
Hopefully now that this has happened: DigiCert will be more reluctant to permit this reseller in the future to have their own custom ordering process --- I would say they should suspend this reseller
Re: (Score:2)
Re: (Score:3)
But why the fuck isn't the PUBLIC key signed, and the end user sends a message to the private key to verify it is authentic?
It is. You generate a certificate signing request (CSR) from your certificate (which embeds the public key and the metadata fields such as organisation name, host name and so on). You send the CSR to your certificate authority (CA). The CA then gives you back a signed certificate (which may strip out some fields from the cert that the CA doesn't want to attest to). The key exchange phase of TLS then sends the certificate to the client, which can walk the certificate chain to verify that someone (hopeful
Re: (Score:2)
>No... it is NOT appropriate for a CA or a reseller of a CA to retain customers' private keys in the first place
Well that's not what I said, is it?
Emailing the keys to someone is an appropriate way to prove to them that the keys have been compromised. Now go and be contrarian somewhere else.
Re: (Score:2)
Emailing the keys to someone is an appropriate way to prove to them that the keys have been compromised.
The keys are compromised for sure so its not inappropriate, but a better method might have been to sign something with the keys as proof instead. Though either way the keys are just as bad off. Now why did digicert only suspend 23k keys instead of the full 50k as was initially reported? digicert is in essence saying they must send all 50k keys before they'll suspend them.
My crystal ball isn't working today. It seems like a really bad idea to be a CA and have people's private keys on file. It seems like a bad idea to be taking people's word for it when you're in a position of issuing revocations. Not my CA. The real CA I set up (in a former job role) held onto nothing but its own keys and the cert list. Certs are needlessly complicated, but you can and should make the process as simple as possible.
Re: (Score:2)
The keys are compromised for sure so its not inappropriate, but a better method might have been to sign something with the keys as proof instead.
What they showed wasn't proof of the compromise the reseller had been claiming happened. What they showed was proof that the reseller had (IMPROPERLY and DELIBERATELY) retained customer private keys, WHICH IS INAPPROPRIATE --- and the reseller then literally compromised their keys (that might not have been compromised before) to "prove" it, which was AL
Re: (Score:2)
ever here of secure file shares?
Re:Bullet, Meet Foot (Score:5, Insightful)
When Jeremy Rowley, an executive vice president at DigiCert, asked for proof the certificates were compromised, the Trustico CEO emailed the private keys of 23,000 certificates
Those certificates are DEFINITELY compromised now.
The first to shoot themselves in the foot would be anyone who doesn't generate their own private key when they purchase a certificate. The CA is only supposed to sign the public parts of your certificate, it is not supposed to ever have access to the private key. Letting your certificate vendor create a private key (and subsequently have access to it) is unwise and insecure.
Re: (Score:2)
Re:Bullet, Meet Foot (Score:4, Insightful)
The level of stupidity expressed in this is staggering. I mean it is not only the fact that somebody with the least bit of clue would never email secret keys without protection, it also is that he could get them in the first place and do this. This means that DigiCert is completely compromised itself due to non-existing or easily bypassed security policies and should under no circumstances be trusted again.
Re: (Score:2)
Re: (Score:2)
Ah, sorry. Thanks for the correction. Then my statement applies to Trustco.
Re: (Score:2)
Those certificates are DEFINITELY compromised now.
Wrong analogy. Bullet meets foot implies that the action of the CEO achieved something other than what he was hoping. He wanted to revoke those certificates anyway, and when questioned whether they were compromised he compromised them.
Nail meets coffin.
Re: (Score:2)
I don't get the fuss. If they are compromised, they are compromised.
That's Nothing (Score:1)
Re: (Score:2)
They use the same key pair for every firewall?
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
it was a re-seller that did this, not the root. DigiCert is the root and they asked for proof from the re-seller that the keys were compromised before they revoked them. The re-seller CEO sent the private keys to DigiCert via standard email with no protection.
Re: (Score:2)
Sophos has a trusted root CA embedded in their enterprise firewalls which allows the firewall to launch man-in-the-middle attacks against clients to spy on them. That means all you have to do to launch a successful man-in-the-middle attack yourself against HTTPS traffic is to gut a Sophos firewall and find the private key embedded in it.
You would have to install the root cert certificate from the firewall CA into all your clients for that to work. In an enterprise if you want to sniff HTTPS traffic, you may chose to do this (since in an enterprise you control the client machines), but as soon as you chose to do this, you open up huge security holes.
Re: (Score:1)
Re: That's Nothing (Score:1)
Re: (Score:1)
Idiots. (Score:1)
What, were they just loose on his desktop next to the vacation photos?
Re: Is SSL just "Security Theater"? (Score:1)
Oh Well, (Score:1)
Dumbasses gotta dumbass.
Either encrypt your email or stop using it (Score:2)
If society isn't going to grow up and start encrypting all email communication, then it's time to get rid of email.
Never give your CEO... (Score:3)
Many CEOs are just technical enough to be dangerous. Never give your CEO:
- Direct access to your database server
- Administrator passwords of any kind, even to their own laptop
- Access to server rooms
- PRIVATE KEYS!
You CAN give a CEO a MacBook Air. They'll be happy with the sleek design, and they won't be able to do much damage, since not a lot of "work" software actually runs on it.
why do executives have access to this type of data (Score:2)
This is why Executives are not kings. There are parts of the business that they should not have casual access to. That is not to say they do not have a right to review and inspect with appropriate parties involved in the process, but access to data and tools like this is not the same thing as keys to the front door.
Re: (Score:2)
The Initial problem was his company had kept copies of the private keys, an absolute no-no and when he(?) found out he wanted to communicate which keys were to be revoked.