VeriSign remedies massive SSL blunder (kinda, sorta) After being publicly outed issuing web credentials that were vulnerable to attacks that could allow criminals to spoof the encryption certificates of any website on the internet, VeriSign has issued assurances it has neutralized any real-world threat. Tim Callan, vice president of VeriSign's product marketing, has said that …
"..all VeriSign SSL products issued on or after December 30 were immune to the attack."
Presumably because they were created using the SHA1 hash? A previous article (http://www.theregister.co.uk/2009/01/07/ssl_security_survey/) states that most issued certificates nowadays use SHA1 instead of the problematic MD5 signatures.
"..If he's wrong and the internet suffers a crippling blow, we'll have VeriSign to thank."
Do we blame locksmiths if burglars develop lockpicking tools? No, we use multiple levels of security for our premises and we use the latest security products as they become available.
The problem will be web-site owners (large corporations, banks, etc) not getting off their fat backsides and upgrading their old MD5 based certificates to SHA1.
Yet another case of foolishly continuing to use a known-broken technology because an easily workable attack, although foreseen and anticipated, has not yet been publicly announced.
Cryptographers have known about weaknesses in MD5 and recommended alternate hashing algorithms since 1996, yet Verisign only now discontinues use of MD5.
Serious DNS flaws have been known for many years, but only the Kaminsky disclosure has brought any real DNSSEC deployment efforts.
Likewise Microsoft and other developers sit on patches until an exploit has been publicly announced and is in the wild, and end users often hesitate to deploy patches that have been released.
Sure there are deployment challenges and costs, but simply doing nothing while vainly hoping that everything will be allright is an unacceptable option that saddles us all with an intolerable burden of risk.
"Mainly that's because the sheer amount of brain and computing power required take the attack out of the grasp of the average internet criminal."
Right, bury your head in the sand. There are plenty of clever hackers out there who would do this for the funnies. Maybe the criminals are a bit thick but the h4x0r kiddes arent.
@Frank
The problem will be web-site owners (large corporations, banks, etc) not getting off their fat backsides and upgrading their old MD5 based certificates to SHA1.
Disagree , they bought what should have been a tested product, the CA should be held responsible and reissue..
Agree, one well known financial organisation, situated in a town with many roundabouts, near the M4, forgot to renew theirs, last year, despite being informed by customers, who in desperation, got on to the CA (in the US, as the UK ones could not be bothered) to inform them of the problem.
Surely the capacity to generate your own certificates allows an SSL proxy, that's massively valuable. I don't need to set up a fake bank site, I just proxy your SSL connection and read your login details.
The returns from that (especially if you combine it with a DNS poisoning attack) are potentially massive. I think that criminals would probably know that, and would assume that they've been looking at this quite hard since 1996 (and then again when the MD5 vuln's were disclosed, assuming they hadn't already cracked it privately).
> The problem will be web-site owners (large corporations, banks, etc) not getting off their
> fat backsides and upgrading their old MD5 based certificates to SHA1.
Err.... no. That's not the vulnerability. MD5 still works well enough that an attacker can't just grab a bank's MD5 based certificate and use it on their attack site.
The new vulnerability is that a hacker could create two specially-crafted certificate requests - one for a domain they legitimately own, and one for a bank domain. They then get Verisign to issue a MD5-based certificate for their legitimate domain. Then they can tweak that certificate to apply to the bank domain.
This attack is possible while any CA issues MD5 certificates; now Verisign have stopped. But once someone has carried out the attack, they can keep using the fake certificate until it expires (typically 2 years).
The right solution is to immediately revoke all MD5 signed certificates (either by using revocation where possible, or by newer browsers just rejecting them). That would result in a lot of pissed-off website owners who had to immediately replace their SSL certificates. (In an ideal world they'd then demand decent security from their new CA vendors, and/or sue their old insecure CA vendors; in practise they're more likely to flame the browser manufacturers, which is why this probably won't happen).
There is a known problem, but an "inconvenient" solution, so instead of actually *doing* anything, pretend that the problem will just not appear.
Just stinks of VeriSign not wanting to impact their bottom line. Fact is they KNOW how many MD5 certs they have issued, they KNOW all the people that have them and the principle contact. All they have to do is oh, contact the individuals and offer (preferably) new free certificates using SHA1/2. Yes it would take ages (</sarcasm>) to query a database to get that information and pump out an email message, but in one swoop they could notify and provide a solution. If free is not in the business manifesto, then a small charge to cover admin costs. To further make people play ball, they could retract the MD5 based signing certs (say within 3 months).
The point is, VeriSign is equipped to sort this out now, with a small amount of technical effort and without playing Russian Roulette with (possibly) 100s of thousands of certificates. Question is more of how much cost and having the balls to act.
Last time I read the "I Agree" license from VeriSign, they basically said the cert was only worth what was paid for it if anything went wrong. Actually, the license is much worse, but that is a digression.
So what do they care if MD5 is used and customers lose vast sums, the cert issuer only loses the cost of the cert. There isn't much incentive to fix the problem until enough bad PR shows up.
I agree that the browsers should just reject MD5 based certs, or at least have a message popup that says 'site xyz is using a weak spoofable cert do you really want to business with clueless losers?'
A few things to remember:
1) VeriSign have been complete wankers since they were formed, so any sort of rational behaviour from them would be highly unusual.
2) If you got an email, supposedly from VeriSign, which said "Please stop using your old cert, and use the attached one instead", how daft would you need to be to do so?
3) What are the odds that said email, probably tarted up beyond all reason in html and 27 fonts, plus fuzzy puppy pix, and allegedly from VeriSign but sourced from some unpronounceable domain, would get through your spam filters?
I'm just sayin'...
In the unlikely event that criminal gangs can't cough up enough crypto smarts and computation, consider how a cryptographically sophisticated and well financed foreign government, say China or Russia, might use the weakness as part of a cyber-warfare initiative.
Once a weakness is known, you gotta fix it. You don't control your crypto-adversary's resources, and you don't know who he is or what his motivation is. This is crypto 101. If the Varisign folks don't know it, then *their* root cert should be revoked. Oh wait, they are the root.
Screwed then.
If the method engineered by the researchers has already been discovered and used by hackers, than any organizations currently utilizing a certificate within their chain (be it the root, an intermediate, or a leaf), could potentially be the victim of a man-in-the-middle attack. Because we have no way of knowing whether or not this is the case, organizations should consider mitigating risk by replacing certificates using the MD5 hash function.
Given this condition, more needs to be done. http://tiny.cc/ns4b8
I see your point, but no, not attach a replacement certificate! I meant a notice saying that the customer should contact VeriSign to have the certificate re-issued. I don't think I was clear enough (or rather presumed that it would follow a renewal notice). Of course no one in their right mind would go and use some attached certificate! but an email concerning cert renewal... and a message to contact your VeriSign rep leaving the customer to make the effort to contact.
I know when I renewed my last wild-card cert I contacted Thawte directly and to the same person that I dealt with the previous time and I think I did get a reminder. So it's not unfeasible really.
Hmm; on second thoughts... yeah you are right - completely dreaming. That would mean "Customer Service" and who the hell does that these days?!
Why don't people get this?
It doesn't matter if sercurebanking.blobby.com has an SHA hashed certificate or not, bad guy can create a certificate which looks like it has been signed validly with the sercurebanking.blobby.com common name in it.
But this still depends on another hack;
DNS, PC compromise (host file, IP redirection etc.) or a network routing/spoofing hack, you can't merely man-in-the middle an https (transparent) proxy, obviously more complex proxies could present a different certificate (like the ISA server functions), but if you have that much control of the network you could just use IP redirects or DNS etc.
If you *only* spoof the certificate then the DNS name won't match and you'll still get a warning (which, yes people still ignore, but they'll also ignore the same unsigned warnings which make the whole hack moot).
What this is, is a lot of excitement that a mathamatical theory has been proven.
Wost case scenaro:
Bad guys duplicate some important websites (paypal?) SSL cerificate, then also have the resources to perform a global DNS hack, they get in quick and steal money - but wait! anything this big would result in sites being closed and accounts locked.
It's a catch-22; the gain would have to be large as any hack requires a huge time investment depending on multiple hacks, but any large scale attack would be detected quickly, so it would need to be small-scale, and if it's small scale then there's easier ways to get the same effect.
in summary...... meh
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
