The first thing is that SSL v2 is deprecated, it can't even be forced anymore.
I you need to quickly test if a server supports SSL v2, you are out of luck with new releases of OpenSSL.
Keep in mind that command "ssl_scan" relies on OpenSSL, so that won't work either.
If you must use OpenSSL you can recompile the newer versions to add SSL v2 support.
It's explained in this link.
This deprecation probably affects more security professionals that just want to know if the Sever is properly configured.
What really affects end users, and might bring some headaches to companies is that OpenSSL no longer negotiates SSL v3, or TLS v1.0.
So if your site doesn't support TLS 1.2 (I'm not sure about TLS 1.1), OpenSSL won't establish the connection, as shown below:
$ openssl s_client -connect *site that does not support tls1.1 or 1.2*:443 CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 305 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---
And as you guessed already, "curl", the command and implementations for different programming languages relies on OpenSSL.
So "curl" will fail too.
Right now you may be wondering why this is important, since all users access sites through web Browsers, which have no problem negotiating TLSv1.0 or SSLv3, the problem arises if you offer any kind of public API.
3rd party developers will have to sort out this problem, because their software will fail at each API request.
Your company might also offer SDK, so you can place some countermeasures there.
The options are not the best.
This is what curl command offers:
-2, --sslv2 Use SSLv2 (SSL)
-3, --sslv3 Use SSLv3 (SSL)
-1, --tlsv1 Use TLSv1 (SSL)
With new OpenSSL versions SSLv2 is deprecated, because it has long been broken.
When OpenSSL 1.0.1d came out SSLv3 was not vulnerable to POODLE, so many forced it.
The problem is that SSLv3 is on the way to be deprecated, so if you just support TLSv1.0 you have to force that.
For some reason if you force TLSv1.0 with "--tlsv1" or "-1" OpenSSL only tries TLSv1.2, and does not fallback.
I couldn't find an easy way to force TLSv1.0
I did an apt-get upgrade of version Ubuntu 14.04 LTS the 22 of January of 2015.
This is the version I've got of curl and OpenSSL
$ curl --version curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
With this version there seems to be no way to force TLSv1.0
I installed php-curl from apt, and read that since version of 7.34 of curl, this options is supported. (http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html)
curl_setopt($connect, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_0);
I checked and I had version 7.35
$ php -i | grep cURL cURL support => enabled cURL Information => 7.35.0
But this is what I got:
PHP Notice: Use of undefined constant CURL_SSLVERSION_TLSv1_0 - assumed 'CURL_SSLVERSION_TLSv1_0' in /home/ubuntu/testcurl.php on line 13
This is the PHP script I made to try this:
<?php $connect = curl_init("https://yourdomain.com"); # curl_setopt($connect, CURLOPT_SSLVERSION, CURL_SSLVERSION_DEFAULT); # does not connect # curl_setopt($connect, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_0); # shows error curl_setopt($connect, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1); # does not connect curl_setopt($connect, CURLOPT_RETURNTRANSFER, true); curl_setopt($connect, CURLOPT_CUSTOMREQUEST, "GET"); curl_setopt($connect, CURLOPT_HTTPHEADER, array("Accept: application/json", "Content-Type: text/json")); $api_result = curl_exec($connect); $api_http_code = curl_getinfo($connect, CURLINFO_HTTP_CODE); print $api_result; print $api_http_code; ?>
So in conclusion:
If you don't support yet TLSv1.2 you are out of luck, you are stuck with SSLv3 till its fully deprecated.
