SSL Holes Found In Critical Non-Browser Software 84
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."
This again? (Score:5, Insightful)
News Flash: People bypass inconvenient security features. Security reduced as a result.
How does this at all lead to a "death knell" for SSL?
Death knell? Really? (Score:5, Insightful)
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?
Protocol (Score:5, Insightful)
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 not an SSL problem (Score:5, Insightful)
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.
Re:Man in the middle? (Score:4, Insightful)
As long as you are using a legit SSL cert ( avalible for less than $10 anually) with decent cipher strength ( again, avalible for less than $10 anually), man in the middle should be impossible with TLS/SSL and the proper use of it by the client ( don't connect and send sensitive data, if the ssl cert isn't valid or the signer isn't trusted).
Re:Man in the middle? (Score:5, Insightful)
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.
Re:This is not an SSL problem (Score:5, Insightful)
This is a problem of bad APIs and people not competent to select libraries with better ones.
While that might sound true, I think the problem is deeper than that. The issue in a lot of cases is developers having to deal with non-ideal SSL/TLS setups that they have no control over.
It usually goes like this:
Dev monkey gets told by PHB, we need to make our communications secure, so implement SSL. Dev monkey adds SSL support to the app. Code seems to work. Testing (or even worse, someone in Production) comes back and says: dev monkey's SSL code doesn't work with our Customer XYZ's server. Dev monkey tests things himself and finds that Customer XYZ is using a self signed cert or an expired cert. Dev monkey tells PHB that Customer XYZ needs to fix their setup. PHB tells dev monkey that the setup cannot be changed because of ABC and that dev monkey needs to "code around the issue". Dev monkey updates app to not choke on bad certs. Code gets released, and Customer XYZ's remote worker gets p0wned by a man in the middle attack. Customer XYZ blames PHB, PHB blames dev monkey. Dev monkey sighs and gets another mountain dew.
Re:Man in the middle? (Score:5, Insightful)
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.
Re:Death knell? Really? (Score:3, Insightful)
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.
Your session is not going to be very opaque if there's a man in the middle listening in.
Re:Death knell? Really? (Score:4, Insightful)
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.
That allows you to have a wonderfully secure conversation with whoever is snooping. Great step forward there!
It's important that clients verify the identity of the servers to which they connect, but they can do so in many ways. Public HTTPS does it in a particular pattern, but a self-signed certificate also works (provided you've distributed the server's public key to clients in a trusted way first). The problem with self-signed on the public HTTPS web is that there's too many sites for it to be at all practical for you to acquire all their self-signed public certificates before connecting to any of them; that advantage (of the CA system) ceases to be very relevant on a closed system such as an intranet, though larger intranets can go for things like a private CA.
Expired certificates or non-matching host certificates are a demonstration of poor deployment.
Re:libcurl is not insecure (Score:4, Insightful)
It is good that the default is secure, but this is bad API design. There are at least two ways it can be improved:
1) The name "CURLOPT_SSL_VERIFYHOST" implies a boolean value, so "set(CURLOPT_SSL_VERIFYHOST, TRUE)" looks like reasonable code after a quick glance. Since the option is a multiple choice option, not a boolean, it should be named something like "CURLOPT_SSL_VERIFYHOST_MODE".
2) C has had enums since forever. The values "1" and "2" are opaque magic numbers, and flags that are this important should be set with well-named enums, not with magic numbers. Further, if the API setter function was typed with the appropriate enums, the compiler would have complained when it saw "set(CURLOPT_SSL_VERIFYHOST, TRUE)".
Yes, the application devs used libcurl incorrectly, and yes, the above criticisms are nitpicks, but a library this important should be designed very defensively to minimize the change that users will make dumb mistakes.