Originally published at: https://boingboing.net/2018/03/04/security-muppetry.html
…
3 Likes
There aren’t any adults in charge, anywhere.
16 Likes
Let me guess, instead of reply, he hit reply to all?
6 Likes
There are some problems with this analysis:
- Trustico isn’t a Certificate Authority. Full stop. They do not issue or revoke certificates. They’re a reseller. They merely cause their partner CAs to issue (and sometimes revoke) certificates.
- It isn’t clear why Trustico wanted those certificates revoked, but an immediate payday (x 50,000) doesn’t strike me as a likely explanation. It would certainly lead to a bunch of pissed off customers, even if their revocation scheme had gone down smoothly (without pushback from Digicert, without publicity, and without destroying Trustico.)
- In addition to the “cold storage” nonsense, Trustico claimed they kept the keys “for revocation purposes”, which makes no sense. The suscriber’s private key isn’t a part of revocation. The issuing CA’s key is, however, required… Which explains why Trustico couldn’t do the revocation, needed Digicert to do it for them.
- Trustico shouldn’t have had the keys in the first place, and certainly shouldn’t have archived them. The former runs against the grain of the whole asymmetric crypto model, and the latter is explicitly forbidden by the Baseline Requirements.
- Trustico is spreading a bunch of word salad FUD (some quoted here) claiming certificates aren’t safe on (?) Symantec/Digicert systems, Digicert defamed them, the keys (which they’d recently emailed) were never compromised, that somehow this kerfuffle is related to the Google/Symantec deprecation issue (it’s not), etc…
7 Likes
What occurs to me is, the more somebody asks for your trust, the more you should hang on to your wallet. Naming your company Trustico is a huge red flag. Like Totally Not Embezzlement, Inc.
12 Likes
Arguably the same for Digicert.
3 Likes
Enh, kinda. If you work with certificates, trust is in a sense literally the product that you’re selling, not just a hyperbolic adjective.
4 Likes
The same is true of banks.
3 Likes
Yeah, you really want something strong, trustworthy, yet vague. Something like “Stratton Oakmont” seems like it’d be a great name for an honest and reputable company.
2 Likes
It’s nonsensical that they would even have the private keys in the first place.
“Trustico CEO, Do you even PKI bro?”
2 Likes
banks are full of trust, just full of it.
2 Likes
You could say it was…certifiable!
Credit Unions and member-owned banks for me only, thank you very much.
Who was it who said something to the effect of when someone tells me how honest they are, I check my pockets?
3 Likes
i believe you’re looking for Emersons “the louder he spoke of his honor, the faster we counted our spoons”
5 Likes
This leaves me wondering if everyone keeps a copy of the private keys they sell. I’m sure governments would encourage that sort of behaviour with bribes and outright payoffs to allow them to decrypt any traffic they want. After all, it’s a whole other revenue stream for CA’s and their resellers.
That’s it! Thanks 
1 Like
This leaves me wondering if everyone keeps a copy of the private keys they sell.
Maybe, but they shouldn’t see the keys in the first place. The process is supposed to look like:
- Subscriber generates a key pair.
- Subscriber uses the key pair to create a Certificate Signing Request (kinda like an un-signed certificate, it contains the subscriber’s public key, and identifying information).
- The CSR is delivered to the CA (or to the RA/reseller who forwards it along to the CA) for signing.
- The CA signs the CSR, turning it into a certificate.
- The certificate is delivered to the subscriber.
The private key never leaves the subscriber. The information transmitted in steps 3 and 5 are not secrets. There’s no opportunity for the CA/RA/reseller to archive the subscriber’s private key because they never got their mitts on it.
Things went wrong in the Trustico case, because they had a certificate “easy button” and people used it. The “easy button” caused steps 1-3 to happen on the Trustico end, and in step 5 they delivered the certificate and the private key to the subscriber… Then secretly archived the private key for mass-compromise at a later date.
This process is explicitly allowed by the Baseline Requirements, but it’s utter insanity and isn’t the usual process. Having said that… I’ve done it. In my case, I needed to provide certificates to end user’s iPhones. It was a hell of a lot easier to send them an email saying “Click this link to get your cert and key” than it was to have them locally generate keys, submit a CSR, etc…
5 Likes
Given the general absolute ignorance about certicates I have met over the years working on IT, it would not suprise me in the least Trustico was giving clients the wonderful service of not having to get their little heads into a knot by generating private keys and CSRs. All that awfully complicated stuff, just let me do it for you and I’ll send you the results.
Really, I’m supposed to be the certificate and TLS expert where I work and ALL I KNOW I GOT BY READING MAN PAGES AND WEB SITES. And I still get a ton of “let me send you the private key, copy the whole universe”, “I have a problem with the SSL handshake because I use a Java that, were it a person, would be about to go senile, so please give me a new cert, that will fix it”, etc…
I worked for a bullshit MLM company once, doing little tech support and random stuff. They trusted me with the weekly company email once and I did exactly that.
I got fired but man was it worth it to watch all those “sales agents” eat themselves. As soon as the got that list of names they all just started marketing to each other. I’m not sure whatever happened but sometimes I dream that I brought down the company.
1 Like
Bias: The company I work for uses Digicert for their certificates (aka, these opinions do not reflect my employer, digicert, etc.)
From my journeyman’s view as the person who owns the internal CA at [RedactedCo] and buys the external certificates, Trustico absolutely violated the trust of the 23,000+ certificates of those keys. Digicert was forced to revoke those certificates by that action.
To my knowledge, I’ve never provided a private key for a ‘normal’ CSR I’ve uploaded to Digicert, nor have they ever asked for one.
It’s very suspicious that Trustico even has those keys and won’t explain clearly why they have them and that the area they are being stored in is secure. It certainly means I won’t recommend them to anyone looking to buy a certificate ever.
1 Like
Hell, what got Symantec into all this hot water was generating keys in a QA environment that were for valid domains that they didn’t control, like some of Googles. There has never been any evidence that those escaped into the wild. Trustico was keeping their customers real private certificats, so if they were stolen, there would be no way to know that they were being misused. I assume that Chrome noticed a bogus key in Symantec’s testing, and phoned home about it.
Also, Symantec wasn’t good enough about policing some of their resellers, and this is further evidence of that.
Now we have CT, Certificate Transparency, with that, all certs will go into public immutable logs, so that if someone issues a bogus cert for your domain, you can know about it, and get it revoked.
1 Like
