Slashdot Mirror
SSL Holes Found In Critical Non-Browser Software
Gunkerty Jeb writes "The death knell for SSL is getting louder. Researchers at the University of Texas at Austin and Stanford University have discovered that poorly designed APIs used in SSL implementations are to blame for vulnerabilities in many critical non-browser software packages. Serious security vulnerabilities were found in programs such as Amazon's EC2 Java library, Amazon's and PayPal's merchant SDKs, Trillian and AIM instant messaging software, popular integrated shopping cart software packages, Chase mobile banking software, and several Android applications and libraries. SSL connections from these programs and many others are vulnerable to a man in the middle attack."
It means that both Gunkerty Jeb and Timothy didn't read TFA and are both fucking stupid.
Summary: libraries allow you to selectively ignore part or all of the certificate chain verification, including OpenSSL, which is exactly what your fucking browser asks you to do when you visit a site with a self-signed or expired cert. TFA argues that this is the wrong behavior. TFA also doesn't understand that sometimes you don't care that much about MITM, just that the traffic is encrypted to make the current session opaque.
TFA also doesn't understand what the layers of security are around Amazon's EC2 toolkit, either.
It means that this "post" is really clickbait. And now we know why no one RTFA.
Yes, it is and it's bs that libcurl got caught in the middle. By default libcurl is secure.
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
There's not really any such thing as a "legit" certificate; you're referring to a signed one. This does nothing to protect against a man-in-the-middle attack. What it does do is establish a chain of trust linking your certificate back to an authority. If that authority is trusted then your cert can be too (to the extent you trust the authority). If, and that's a big if, we trust that _all_ trusted authorities will thoroughly vet the certificates they sign then we can _trust_ that a MITM attack cannot occur, but realistically "legit" certificates do nothing more than that. If, say, the US DoD (once/often? a trusted authority) decides to MITM you, they can just sign a cert and MITM you.
The only way to actually prevent MITM is to exchange the certificate (or some verification mechanism like a hash) in some sort of trusted manner (e.g. distributing it's hash with a client app).