TTP means Trusted THIRD Party

Posted in Certificate Glitches, Networking Faux Pas, Crypto Plumbing on December 7th, 2011 by Rodney

Check out It’s got a certificate for “*”. Wildcard certs may be the “store the used control rods in the attic and forget about them” technical trick of the certificate world. But wait, it gets better. This was issued by the “Google Internet Authority”. This presumptuous name describes a Certificate Authority, operated by Google (a/k/a, that is in turn signed by a GeoTrust root.

Uh, guys, the point of certificates was to introduce a “trusted third party” (see Wikipedia definition or use BING to search for the term yourself…)

When the company running the web site issues the cert for a public TLS-protected website, the point was to be able to trust it because SOMEONE ELSE was the trusted third party. That’s why they are the THIRD party (not the first party, the browser user, called the “relying party” in certificateSpeak, or the second party, the private key holder of the site being accessed via “https”.)

Other sites do this. Akamai has in the past (and may still) practice this “I’m the second party and the third party” stunt.

Is this bad? Yes, this is bad. There’s no trust here. You’re only trusting the web site operator. If they are compromised, or go rogue, you’ve got no recourse. Revoking the certificate is no longer a defense. Trusting the root is no longer a defense. And, it implies these retail certificate authorities will take money for all sorts of crazy non-trust-delivering practices.

Trust was SUPPOSED TO means “trust the web site operator”

Posted in Certificate Glitches, Networking Faux Pas, Crypto Plumbing on December 7th, 2011 by Rodney

Check out this . Note the hostname mismatch (it’s got a GeoTrust cert for Note the WEB TRUST seal in the upper right corner. Click on that, let Chrome kindly translate (appologies, I don’t read Russian or Ukranian.) Note the seal is from “” (confused yet?) and THAT says “Verisign Trusted” (Verisign != GeoTrust.) Note also the default Plesk self-signed certificate.

So… you should trust these certificates? From several different CA’s, and from a site that uses self-signed certificates? Not to pick on Symantec’s Ukrainian trading partners… but really, are we supposed to trust these certificates? When the vendors are this sloppy?

D/R 201: Maintain Fresh Batteries

Posted in Physical Security Infrastructure, Networking Faux Pas, Crypto Plumbing on May 30th, 2011 by Rodney

Years ago, at the dawn of the dot-Com age, when crypto was cool and Distinguished Names were already an arcane concept, there was a story, let’s be kind and say it’s an urban legend, about root keys.  In the early days you bought a BBN Safekeeper.  It kept the RSA private key safe.  It had a battery backup on the memory it used to store the keys (remember this would have been 1980’s tech.)

There was this story about how American Express bought a Safekeeper but forgot to change the batteries.  I’m not sure it’s true but it does point out the need for the key operator to follow policy and use the “split the key and save the parts in separate places” features of modern HSM solutions.

More generally, you should buy a UPS.  Or at least make sure someone’s making sure your expectations about continuous clean in-budget power are met.  Buy a UPS, make sure you plug into the “special” power strip in the Colo, confirm the D/R plan is NOT on your task list, or somehow think about it.  At least think about it for a moment.