Secure Certificate Hack Doesn't Imperil Users

At 19:51 -0800 UTC, on 2009-01-03, LewisGmail wrote:
> I thought the key to breaking Enigma<1> was [...]

Heh. That reminds me. One of the most entertaining books I've read in recent
years is "Cryptonomicon", by Neal Stephenson:
<http://www.amazon.com/Cryptonomicon-Neal-Stephenson/dp/0060512806/>.
Encryption of all sorts, from rot3 through Enigma to PGP and beyond, plays a
major role in it, and, although it *is* fiction, the author clearly
understands what he writes about.

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

There are a number of books published over the years about the Enigma
Machine, including Enigma by Robert Harris published I believe in the
1980s with a trade paperback in 1996. See the listing at Amazon.com.
Also, see the lengthy discussion at Wikipedia, http://en.wikipedia.org/wiki/Enigma_machine

At Amazon, you can buy a mouse pad with the German machine depicted on
it.

Dave Clark
www.clarklawfirm.com
http://daveclarkimages.smugmug.com
http://twitter.com/dave30c

I was sold on using EV certs when I heard a claim and checked into it, that, "EV certs are un-hackable." That's a bit like throwing down the gauntlet, a statement like that. They're asking for trouble. While I'd never myself make such a claim, it was worth checking into.

The validation was indeed extensive--very, and when the "not to be named" CA did finally validate us, they also threw us an unexpected challenge; they use an intermediate issuing CA, child to the parent, the root cert. That intermediate CA is relatively obscure, and does occasionally cause issues when a user's browser is only looking at the root; it misses the intermediate and thus the EV lookup fails.

But if one trusts that intermediate, it works quite well. Much as one is prompted for an unknown, "trust me, really!" cert, this one must be trusted by the user for it to work seamlessly---if a browser doesn't do a full lookup using the signature. An enterprise could do a push to corporate desktops, I suppose, but it's just as easy to hand or point them to it, asking them to trust it. At least in small volumes of users. En masse, it would be another thing entirely, getting massive amounts of users to find and trust an intermediate cert.

In the end, that's what all this hoopla is about, trust. The CA is vouching for the cert in question. Seems like for any issuing CA to be really trusted, they need to re-issue MD5 based certs... because it's all about trust, and who can anymore trust an MD5 based one?

--On January 7, 2009 12:10:03 AM -0800 Sander Tekelenburg
<tekelenbeuronet.nl> wrote:

> Heh. That reminds me. One of the most entertaining books I've read in
> recent years is "Cryptonomicon", by Neal Stephenson:
> <http://www.amazon.com/Cryptonomicon-Neal-Stephenson/dp/0060512806/>.
> Encryption of all sorts, from rot3 through Enigma to PGP and beyond,
> plays a major role in it, and, although it *is* fiction, the author
> clearly understands what he writes about.

Great book. By the way, the Solitaire (or Pontifex) encryption scheme used
in one section of the book is real, it was designed by Bruce Schneier for
Neal Stephenson to use.

<http://www.schneier.com/solitaire.html>

On 07Jan2009, at 00:10, sscarbrough wrote:

> who can anymore trust an MD5 based one?

The attack by Sotirov et al. didn't create just a way to forge MD5
based certificates, it created a way to forge CA (certificate signing)
certificates. As far as I know, that CA certificate could then be used
to sign forged certificates that were hashed with SHA-*. At the very
least, the user would have to check the entire certificate chain to
the root to be sure there were no MD5 signers involved. At least in
Safari, that's difficult for an end user to do.

Aanother interesting issue, since you mentioned EV certificates: EV
certificates might be secure, but now we know that signing
certificates for plain old SSL certificates have been forged. I can
alter a name server to redirect, say, https://
sitekey.bankofamerica.com/ to a server of my own. I can create a
forged SSL certificate for my server. How many people who visit my
site will notice that they're connecting with a regular SSL
certificate and not an EV certificate? I doubt it would be 100%. There
would be no warning from the browser -- the user would have to notice
that (in Safari) the site name doesn't appear by the lock icon. It's a
bit more obvious in other browsers, but I doubt user recognition
approaches 100% in any case.

We need browsers that check the whole certificate chain for MD5-hash
based signatures, and at the very least put up a warning when they
detect such certificates.

On a closely related issue, does anybody know if or how often modern
browsers check key servers for revoked certificates? If they do, is it
in a way that protects users' privacy?

--Ron
www.risley.net

A lot of good information here on this issue. Ron, I'm also curious how often browsers check for revoked certs -- I know I'm alerted every time I navigate to a site that has an expired cert, but that's a different issue. And of course any self-signed or forged certs I can't tell from legit ones.

One thing I've been hearing lately -- not only from this thread but from the IT gurus I work with -- is that the biggest obstacles to making SSL more secure, especially on the EV side, lie squarely with browser technology. CA's and cert designers can create all the robust security measures they want -- ie, the fact that EV cannot be forged -- but if your major browsers don't recognize the difference then it's a lot of lost effort. It's in a way unfortunate that everyone concentrates on the "green url" aspect of EV, since that only speaks to the noticeable security changes and the green url has had a slow adoption. But I've seen a handful of sites that had no green url and were still technically EV encrypted. The problem is not just technology or security, it's -- as Ron pointed out -- user recognition. Since the peril lies with users' decisions, they need to be better armed to make prudent ones.