A team of security researchers and academics has broken a core piece
of Internet technology. They made their work public at the 25th Chaos
Communication Congress in Berlin today. The team was able to create a
rogue certificate authority and use it to issue valid SSL certificates
for any site they want. The user would have no indication that their
HTTPS connection was being monitored/modified.
25C3: Hackers Completely Break SSL Using 200 PS3s | Hackaday
Creating a rogue CA certificate
That's a bit of a stretch. It doesn't seem that they've actually broken
"a core piece of Internet technology." It's more like they've nibbled at
a known potential problem enough to make it a real problem.
According to the quoted article, "They collected 30K certs from Firefox
trusted CAs. 9K of them were MD5 signed. 97% of those came from RapidSSL."
I've seen other discussions of the topic that suggest that a variety of
CA's (one such discussion talked about "VeriSign resellers", and I believe
RapidSSL ~== VeriSign) are vulnerable.
Anyways, I was under the impression that the whole purpose of the
revocation capabilities of SSL was to deal with problems like this, and
that a large part of the justification of the cost of an SSL certificate
was the administrative burden associated with guaranteeing and maintaining
the security of the chain. It seems like the major browser vendors and
anyone else highly reliant on SSL should be putting VeriSign and any other
affected CA's on notice that their continued existence as trusted CA's in
software distributions is dependent on their rapidly forcing customers to
update their certificates, an obligation that they should have expected to
undertake every now and then, even though they'll obviously not *want* to
have to do that.
I'm aware that the VeriSign position is that their existing certificates
are "not vulnerable" to "this attack," which I believe may be the case for
some values of those terms. However, it is often the case that a limited-
effectiveness example such as this is soon replaced by a more generally-
effective exploit, and the second URL suggests to me that what VeriSign is
saying may not be true anyways.
... JG
How to revoke the CA is actually in the file. The fake CA they created didn't have any revokation.
MD5 is broken, don't use it for anything important.
The reason for their exercise is just as you said, they executed in practice what had been said to be possible since around 2004-2006. This is obviously needed for people to start paying attention.
What percentage of deployed browsers handle CRL's correctly?
Consider this snippet from the phreedom.org page (section 6.1):
"One interesting observation from our work is that the rogue certificate we
have created is very hard to revoke using the revocation mechanism available in
common browsers. There are two protocols for certificate revocation, CRL and
OSCP. Until Firefox 3 and IE 7, certificate revocation was disabled by default.
Even in the latest versions, the browsers rely on the certificate to include a
URL pointing to a revocation server. Our rogue CA certificate had very limited
space and it was impossible to include such a URL, which means that by default
both Internet Explorer and Firefox are unable to find a revocation server to
check our certificate against."
Hmm... so basically all deployed FireFox and IE either don't even try to do
a CRL, or they ask the dodgy certificate "Who can I ask if you're dodgy?"
What's wrong with this picture? (Personally, I consider this a potentially
bigger problem than the MD5 issue...)
Hmm. Don't the shipped-with-the-browser trusted root certificates
include a CRL URL?
Every CA runs its own CRL server -- it has to be that way.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
But the engineered certificate won't be considered trusted if its whole chain back to the root isn't trusted, and one or more of the certificates in that chain should have been shipped with the browser and hopefully includes a CRL URL.
Although they won't want to, surely the roots should revoke their root certificates that issued MD5-signed certificates, and issue new root certificates for issuing SHA-1-signed certificates. Browsers would then stop trusting all the MD5-signed certificates due to them not having a trusted chain back to the root, assuming they bother to check all the certificates in the chain for revocation.
Of course, this will just make the browsers pop up dialog boxes which everyone will click OK on...
Of course, this will just make the browsers pop up dialog boxes which
everyone will click OK on...
And brings us to an even more interesting question, since everything is trusting their in-browser root CAs and such. How trustable is the auto-update process? If one does provoke
a mass-revocation of certificates and everyone needs to update their browsers... how do the
auto-update daemons *know* that what they are getting is the real deal?
[I haven't looked into this, just bringing it up. I'm almost certain its less secure than the joke that is SSL certification].
Happy New Year!
Deepak
If done properly, that's actually an easier task: you build the update
key into the browser. When it pulls in an update, it verifies that it
was signed with the proper key.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
If done properly, that's actually an easier task: you build the update
key into the browser. When it pulls in an update, it verifies that it
was signed with the proper key.
If you build it into the browser, how do you revoke it when someone throws 2000 PS3s to crack it, or your hash, or your [pick algorithmic mistake here].
Deepak
For IE and other things using CryptoAPI on Windows, this should be handled through the automagic root certificate update through Windows Update (if one hasn't disabled it), AFAIK.
The question is really whether that mechanism requires a cert rooted at a Microsoft authority or not. The danger being that someone could use an intermediate CA rooted at an md5-signing CA and present a seemingly valid cert through that with the right common name.
Some other Microsoft things (i.e. KMCS) require certs rooted to a single specific root and not just *any* global root, so it's possible that the same is done for root certificate update blobs; however, I don't know for certain, and some research would need to be done. I don't think any of the MS issuing roots use md5, though.
- S
If you use bad crypto, you lose no matter what. If you use good
crypto, 2,000,000,000 PS3s won't do the job.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
If you use bad crypto, you lose no matter what. If you use good
crypto, 2,000,000,000 PS3s won't do the job.
Even if you use good crypto, and someone steals your key (say, a previously in-access person) you need a way to reliably, completely, revoke it. This has been a problem with SSL since its
[implementation] inception. Lots of math (crypto) is good on paper and fails at the implementation stage.
Deepak
You mean like for BGP neighbors? Wanna suggest an alternative? 
-Hank
Well, most likely MD5 is better than the alterantive today which is to run no authentication/encryption at all.
But we should push whoever is developing these standards to go for SHA-1 or equivalent instead of MD5 in the longer term.
Hank Nussbacher wrote:
You mean like for BGP neighbors? Wanna suggest an alternative? 
tcp/md5 + gtsm (assuming directly connected peers) makes messing around
with bgp sessions rather difficult. Filtering BGP packets at the edge and
borders slightly more so. If you have CPU and sufficient quantities of
administrivium to spare, you can use ipsec on your routers for these sessions.
The real issue is how to make compromising bgp sessions sufficiently
difficult to make it an unattractive target. Given that the cost of
getting write access to the DFZ is not really very high either technically
or financially, I'd propose that while gtsm / md5 / filtering aren't
perfect, they raise the bar high enough to make it not really worth
someone's while trying to break them; and IPsec more so.
Nick
* Hank Nussbacher:
MD5 is broken, don't use it for anything important.
You mean like for BGP neighbors?
Good point. However, as a defense against potential blind injection
attacks, even an unhashed password in a TCP option would do the trick
(at least in the non-IXP case, IXPs may pose different challenges).
Wanna suggest an alternative?
Just switch on IPsec. 
* Hank Nussbacher:
Who is working on this? I don't find anything here:
Inter-Domain Routing (idr)
I think this belongs to the tcpm WG or the btns WG.
Yeap:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-02.txt
TCPM WG J. Touch
Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ.
Expires: May 2009 R. Bonica
Juniper Networks
November 3, 2008
Rubens