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."
News Flash: People bypass inconvenient security features. Security reduced as a result.
How does this at all lead to a "death knell" for SSL?
The death knell for SSL is getting louder
What does this mean? Just that vendors should be using the newer versions of SSL that were rebranded TLS? Or is there another, competing technology that is recommended instead?
How is the wrong implementation of a protocol in a framework library a fault of the protocol?
Either devs need to be aware that there's extra steps in validating using an SSL library in their framework of choice, or the framework needs to be patched appropriately, but based on the concepts the article's provided, sounds like bad implementation aka crap code, and not enough QC. Some OOP would help make the implementation easier though...
This is a problem of bad APIs and people not competent to select libraries with better ones. The same would happen with any other encryption protocol. Implementing and using cryptography is hard, in particular because testing will usually not show anything is wrong and testing is still the only thing most software "developers" have in their bag of tools to ensure correctness. As long as people without a clue decide they can implement cryptographic libraries or use them, these things will continue to happen.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The compliant about libcurl is baseless. It's said VERY CLEAR in the documentation how to use the feature. If stupid devs can't figure it out that's hardly the fault of a library developer. I've never had an issue with it and I've used it in C, C++, and PHP.
To repeat what I said on the mailing list. If I break my thumb with a hammer do blame the hammer or do I blame myself?
As Yehezkel Horowitz pointed out on the mailing list.
This is the quote from the FAQ
>Q: How do I use cURL securely?
>A: CURLOPT_SSL_VERIFYPEER must be set to TRUE, CURLOPT_SSL_VERIFYHOST must be left to its default value or set to 2. Anything >else, such as setting CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection being insecure against a man-in-the-middle attacker.
The real answer should be - cURL defaults are secure - no need for any code to use it securely.
==================
In general I think the very short answer for this publication should be RTFM.
The little bit longer answer would be -
1. cURL is a C code library - you can't set a value to TRUE since this is not in the language syntax.
So you has somewhere in your includes something like "#define TRUE 1" - you must be aware to this issue - this is an important part of the relations between computers/compilers/programmers.
2. Before setting any option to cURL - you should read the very clear documentation about this option.
==================
As to what we can do to make cURL even better (in order to protect unprofessional users that don't know what they are doing), We could make '1' to act as '2' (verify peer identity), and add a special magic value (i.e. 27934) that will act as todays '1' (check for CN existence but don't verify it).
I think they owe everyone at libcurl an apology.
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
You're better off running your own CA and distributing that CA's public key to your internal apps. Then you can ignore outside CAs but still avoid MITM attacks.
rage, rage against the dying of the light
The current versions of SSL/TLS are never vulnerable to man-in-the-middle attacks unless a trusted certificate authority is compromised (as long as both client and server implement RFC 5746). Whether the certificate authorities are trustworthy is another question, of course.
This particular problem is caused by folks disabling the SSL stack's built-in chain validation and then not implementing their own. As far as I know, there are exactly two correct ways to support self-signed keys in Android: provide your own trust store that includes trust for that specific self-signed key or subclass the X509 validation class to add that specific self-signed key as an additional trusted anchor into the list of trusted anchors that it returns. Unfortunately, there's a lot of very bad advice out there, particularly on sites like Stack Overflow, telling folks to disable chain validation entirely. The result is that not only does the app trust that self-signed key, it also trusts any self-signed key.
It doesn't help that there's no canonical source for that information from Google, so there are many, many questions on sites like Stack Overflow that all ask the same basic question in different ways and get different answers....
Patient: Doctor, when I drill a hole in my hand, I can't scoop up water from the bucket to drink.
Doctor: Why did you drill a hole in your hand?
Patient: So that the acid wouldn't stay in my hand.
Doctor (alarmed): Why did you put acid in your hand?
Patient: Because the bucket dealer wanted too much money for a bucket.
Yeah, it's like that.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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).