The most dangerous code in the world

The worst example from this paper is Curl's API.<p>Curl has an option, CURL_SSL_VERIFYHOST. When VERIFYHOST=0, Curl does what you'd expect: it effectively doesn't validate SSL certificates.<p>When VERIFYHOST=2, Curl does what you'd expect: it verifies SSL certificates, ensuring that one of the hosts attested by the certificate matches the host presenting it.<p>When VERIFYHOST=1, or, in some popular languages, when VERIFYHOST=TRUE, Curl does something very strange. It checks to see if the certificate attests to any hostnames, and then accepts the certificate <i>no matter who presents it</i>.<p>Developers reasonably assume parameters like "VERIFYHOST" are boolean; either we're verifying or we're not. So they routinely set VERIFYHOST to 1 or "true" (which can promote to 1). Because Curl has this weird in-between setting, which does not express any security policy I can figure out, they're effectively not verifying certificates.

I agree that these APIs are fundamentally difficult to use correctly (sometimes it almost seems as if they've been designed to trick you), and that developers commonly get them wrong, but this paper is perhaps a little more inflammatory than it should be.<p>They cast a really wide net, looking for as many examples as possible where non-browser applications fail to do SSL validation correctly, but then conclude that this will result in a security compromise without fully examining the implications.<p>For instance, they point out that many SDKs for Amazon FPS don't validate certificates correctly. But I didn't see them mention that the FPS protocol does its own signature-based authentication and that credentials are never transmitted in the clear: it was essentially designed to operate over an insecure transport to begin with.<p>Likewise, they point out an "unsafe" construction that an Android application that I wrote (TextSecure) uses. But they don't mention that this is for communication with an MMSC, that this is how it has to be (many don't present CA-signed certificates), and that the point of TextSecure is that an OTR-like secure protocol is layered on top of base transport layer (be it SMS or MMS).<p>So I think the paper would be a lot stronger if they weren't overstating their position so much.

The title should be renamed to:<p>Many security flaws found in commonly used SSL libraries.<p>Other than that, it is a great find.

How ironic. Even these guys hosting a paper about SSL can't host their stuff securely on an HTTPS server.<p>&#60;base href="<a href="http://crypto.stanford.edu/~dabo/pubs/pubs.html&#62" rel="nofollow">http://crypto.stanford.edu/~dabo/pubs/pubs.html&#62</a>;<p>This causes the page to throw an HTTPS warning: "this page loads insecure content" due to the css loaded over HTTP.

From the PDF linked in the article:<p>"Not the most interesting technically, but perhaps the most devastating (because of the ease of exploitation) bug is the broken certificate validation in the Chase mobile banking app on Android. Even a primitive network attacker—for example, someone in control of a malicious Wi-Fi access point—can exploit this vulnerability to harvest the login credentials of Chase mobile banking customers."

Sounds like it might be easier to list the options that actually do the Right Thing. If you're using Python, for example, the correct way to make HTTP requests is to ignore the standard library's urllib and (shudder) urllib2, and use Requests instead:<p><a href="http://docs.python-requests.org/en/latest/" rel="nofollow">http://docs.python-requests.org/en/latest/</a><p>It validates SSL certificates correctly by default. How about other languages?

I notice that whenever I use "wget <a href="https://github.com/" rel="nofollow">https://github.com/</a>[...]" I always end up typing wget --no-check-certificate because the first try never works.<p>I suppose my web browser has an extended list of CA that my OSX lion does not know about.

So of all the possible futures we could have, ones where we use computers to give us crypto, good security and privacy etc, instead we end up with Masamune Shirow's admitted guess of Ghost in the Shell where people can't properly use their arms due to 5 different version of the driver installed and people having 10 different viruses IN THEIR BRAINS and are constantly getting hacked and having their bodies taken over.

they make this point in the paper, but still it surprises me - the level of testing for payment frameworks seems surprisingly minimal. it's pretty easy with openssl to roll your own certificates to test a bunch of different issues. you'd think that the people involved would have quite an incentive to test well.<p>i'm not saying that this would solve all the problems, or that you should develop critical financial software by having people that don't understand much writing tests. but tests are pretty much common culture now; you'd think people would have considered this. and the argument the paper makes is not that the programmers are clueless, but that they are confused by the API, so they should be able to think up some useful tests...<p>of course, integration testing with sockets is a bit more complicated than unit tests (perhaps something toolkit apis should support is a way to allow testing without sockets?), but it's not super-hard. [edit: hmm. although testing for unreliable dns is going to be more tricky.]

The title is a bit sensationalist - there was incorrect code and it made the copy/paste rounds. Presumably all incorrect code is dangerous to some degree but I'm certain there's a more fitting title for this story.<p>At any rate, here is a pull request for PHP which attempts to address the issue:<p><a href="https://github.com/php/php-src/pull/221" rel="nofollow">https://github.com/php/php-src/pull/221</a>

I have only read the first two sections, but the prose in this paper is a breath of fresh air. It is clear and strong.

Slightly related, link to Peereboom's rant on the OpenSSL library (a bit dated): <a href="http://www.peereboom.us/assl/assl/html/openssl.html" rel="nofollow">http://www.peereboom.us/assl/assl/html/openssl.html</a>

I came across this issue when using node.js to make secure requests as a client and after setting up tests with bad certs found it silently worked anyway. To get it working you need to be at a certain version of node.js and make sure you set the options up carefully. Testing with a bad certificate is essential for this stuff. <a href="http://stackoverflow.com/questions/10142431/my-node-js-https-client-always-works-regardless-of-certificate-validity" rel="nofollow">http://stackoverflow.com/questions/10142431/my-node-js-https...</a>

So how soon until we start seeing developers fix these gaping holes? And, more importantly, how soon do we start seeing app-specific exploits that take advantage of this problem?

And odds are the guys that wrote this paper don't have any clue that even if those writing the CLI tools/libraries/frameworks that use SSL had locked them completely down, developers and sysadmins would write scripts to agree-to-all, fake auth, etc. to get around security, because we have jobs that have to get done and security is not what we are all paid to do. Security is only critical when it fails. People claim to want security. They may even have an office of security. But even if that office of security is scanning all the apps, taking production apps down because they didn't throttle their probes, and maybe even looking at code- they cannot do the job of the developer.<p>It is destined to be flawed as long as insecurity is allowed. Only when every exploit is exploited continously will people be vigilant.

Anyone have an example of good cert verification in Java? The concept at <a href="https://github.com/iSECPartners/ssl-conservatory" rel="nofollow">https://github.com/iSECPartners/ssl-conservatory</a> is great, but it needs examples in more languages. Our case is pretty weird (some self-signed certs between peers, cert pinning of sorts in that we only accept equifax as a root signer, no default signing authorities accepted), but anyone see holes in the authenticate method of our trust manager at:<p><a href="https://github.com/getlantern/lantern/blob/master/src/main/java/org/lantern/LanternTrustManager.java" rel="nofollow">https://github.com/getlantern/lantern/blob/master/src/main/j...</a><p>? This code is intended for deployment in potentially dangerous regions for getting around government censors.<p>Thanks.

I noticed this the other day in Rails. ActiveResource::Connection in 3.2.8 is affected in that the default OpenSSL verification mode is "OpenSSL::SSL::VERIFY_NONE". A developer has to explicitly set it for SSL validation.<p>You can see it here: <a href="https://github.com/rails/rails/blob/3-2-stable/activeresource/lib/active_resource/connection.rb" rel="nofollow">https://github.com/rails/rails/blob/3-2-stable/activeresourc...</a><p>I'm pointing it out as it was not mentioned in the paper.<p>Edit: It looks like it has been that way since SSL was first implemented in Connection.

2010, Certificate verification is essential to TLS.<p>require 'always_verify_ssl_certificates' AlwaysVerifySSLCertificates.ca_file = "/path/path/path/cacert.pem"<p>http= Net::HTTP.new('<a href="https://some.ssl.site" rel="nofollow">https://some.ssl.site</a>, 443) http.use_ssl = true req = Net::HTTP::Get.new('/') response = http.request(req)<p><a href="http://www.rubyinside.com/how-to-cure-nethttps-risky-default-https-behavior-4010.html" rel="nofollow">http://www.rubyinside.com/how-to-cure-nethttps-risky-default...</a>

Everyone who does any development should read this paper. It is not just for SSL specialists!

Are Rack-based middleware affected by these vulnerabilities (or did I lose the plot)?

"...bad implementations of SSL like OpenSSL..."<p>&#60;falls off chair&#62;