PHP Curl (with NSS) is probably using SSLv3 insted of TLS when connecting to https
I have Curl 7.21.7 and PHP 5.4.34, and this seemed to do the trick for me:
curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
More info here, although it doesn't say when CURL_SSLVERSION_TLSv1 was introduced.
I'm using curl library (with NSS) in PHP to connect to my other server. Everything was fine until last week, when the destination server stoped supporting SSLv3 due to poodle vulnerability (CloudFlare by the way). Now, I'm trying to make connection using TLS, but I'm still getting "SSL connect error".
There is sample code, I'm using:
$ch = curl_init(); curl_setopt_array( $ch, array( CURLOPT_URL => 'https://www.lumiart.cz', CURLOPT_RETURNTRANSFER => true, CURLOPT_SSLVERSION => 1, CURLOPT_SSL_VERIFYPEER => false, CURLOPT_VERBOSE => true ) ); $output = curl_exec( $ch ); echo $output; print_r( curl_getinfo( $ch ) ); echo 'error:' . curl_error( $ch ); curl_close($ch);
From my understanding, setting
1 should force connection via TLS.
Note: I have
CURLOPT_SSL_VERIFYPEER => false just for debuging and I'm not meaning to leave it there, once I figure this problem out.
This is output:
Array ( [url] => https://www.lumiart.cz [content_type] => [http_code] => 0 [header_size] => 0 [request_size] => 0 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 0 [namelookup_time] => 2.3E-5 [connect_time] => 0.005777 [pretransfer_time] => 0 [size_upload] => 0 [size_download] => 0 [speed_download] => 0 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => -1 [starttransfer_time] => 0 [redirect_time] => 0 [certinfo] => Array ( ) [primary_ip] => 2400:cb00:2048:1::681c:86f [redirect_url] => ) error:SSL connect error
I have all of this at shared hosting provider, so I can't change any php.ini configuration or update any components. All I have is phpinfo(). I've checked for TLS support on these components version and it should be fine. Here is excerpt of phpinfo:
PHP Version 5.4.32 System Linux wl42-f262 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 curl: cURL support enabled cURL Information 7.19.7 Age 3 Features AsynchDNS No Debug No GSS-Negotiate Yes IDN Yes IPv6 Yes Largefile Yes NTLM Yes SPNEGO No SSL Yes SSPI No krb4 No libz Yes CharConv No Protocols tftp, ftp, telnet, dict, ldap, ldaps, http, file, https, ftps, scp, sftp Host x86_64-redhat-linux-gnu SSL Version NSS/3.15.3 ZLib Version 1.2.3 libSSH Version libssh2/1.4.2
I think, that problem is usage of SSLv3 instead of TLS, but I'm not 100% sure. All I'm geting is "SSL connect error" and I don't know, how to find out, which SSL version was used to connect.
Is there a way, how to check, which SSL version is used for connection? Or am I missing something?
Thanks for any advice!
SSL error can not change to TLS
CURLOPT_SSL_CIPHER_LIST => 'TLSv1'
PPHttpConfig.php file. I had the same issue with you and spent hours to find the solution. This worked for me.
This comes up when searching for Magento Error:14077410:SSL Routines:SSL23_GET_SERVER_HELLO:sslv3 Alert Handshake Failure! If you are trying to solve that, here is the link to the guy who originally solved the issue along with a downloadable patch: https://www.dwdonline.com/blog/fix-magento-error14077410ssl-routinesssl23_get_server_hellosslv3-alert-handshake-failure.html It's the same error - just in another software package.
Php - cUrl support TLSv1 connection
- TLSv1: use TLS 1.x, i.e. TLS 1.0, TLS 1.1, TLS 1.2. These might not be all available depending on the underlying implementation.
- TLSv1_0: use only TLS 1.0, i.e. no TLS 1.1, TLS 1.2 even if the implementation would support this.
If your implementation supports at most TLS 1.0 then both options should have the same effect.
BTW, the very first hit with google when searching for "CURL_SSLVERSION_TLSv1_0 CURL_SSLVERSION_TLSv1" is http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html which documents these options as:
- CURL_SSLVERSION_TLSv1: TLS 1.x
- CURL_SSLVERSION_TLSv1_0: TLS 1.0
A better solution until Paypal updates its core SDK would be to override the CURLOPT_SSL_CIPHER_LIST directly in your application. This way you don't have to interfere with the sdk-core-php package directly and you will be free to upgrade it in future.
You could add something like the following to your app's bootstrap or payment processing logic:
PPHttpConfig::$DEFAULT_CURL_OPTS[CURLOPT_SSL_CIPHER_LIST] = 'TLSv1';
Just make sure you comment it thoroughly and remember to take it out later when the issue has been patched in the core.