Null-Prefix SSL Attacks Enabled In New sslsniff 48
An anonymous reader writes "Moxie Marlinspike, who recently published new attacks on SSL at Defcon 17, seems to have released the new version of sslsniff which supports these attacks. While the release appears to coincide with a patch from Mozilla, every product that uses the Microsoft CryptoAPI is still vulnerable, including Internet Explorer and Outlook. The new version of sslsniff also supports built-in modes for hijacking software auto-updates that depend on SSL, and apparently includes techniques for defeating OCSP as well — making the elimination of existing null-prefix certificates difficult."
Protocols (Score:3, Interesting)
Just wondering... will this help analysis of some "secured" protocols, maybe?
I don't know how it works, but let's say something like Steam uses SSL or similar (I have no idea if it does, just pretend)... before we couldn't do the protocol analysis without a massive reverse-engineering going on (could only see "client to server" messages because we only have access to the client's private key). Now we might be able to fool non-patched SSL programs to believe that they are talking to an authentic server without having to delve into their code and thus be able to see / fake both sides of the conversation?
Am I way off the mark, or is this now possible with unpatched programs relying on SSL etc. layers to hide their protocols?
Yeah, right (Score:3, Interesting)
That is the first thing they think of. You can bet your lunch money that they statically link their crypto library, and then obfuscate the binary for good measure.
Re:Appears to coincide.. (Score:4, Interesting)
You're absolutely right. If this guy didn't inform anyone except Mozilla, he's bringing browsers wars to a new low, by being willing to expose a majority of web users involved in e-commerce and other "secure" online access to his vulnerability for whatever the lead time of patching is, but exempting users of his favorite browser. IF that's what he did, that's ridiculous, childish, and petty.
What about all the other vendors of SSL dependent software? SSL based VPNs like OpenVPN for example. No love for them either? Just Mozilla?
It shows how people like Dan K are smart enough to recognize major vulnerabilities that can potentially affect massive amounts of service/traffic/commerce need to be handled differently. It doesn't reduce the respect you gain as a security researcher for finding such a major flaw to give vendors notification in a reasonable time period before publication. I'm all for full disclosure as a means of punishing companies that don't respond, but for larger vulnerabilities I think notification and a deadline are the way to go.
Re:Yeah, right (Score:2, Interesting)
Mua-ha-ha-ha.
I've run into one of those annoying runtime licensing systems that not only uses out-of-the-box static build of OpenSSL in its code, it's an older version, too.
Unobfuscated. With all the original OpenSSL symbol names. But they don't provide _all_ of OpenSSL, so you can't just use their old & busted one.
Yes, this causes a serious multiple-definition problem if you want to use that library in an SSL application.
Their "fix"? "Remove these filenames from the .a file we sent you. And these ones. And these, too."