paypal turning off sslv3 support due to POODLE

Does anyone know,

Do the native paypal modules or any of the modules define cURL use for sslv3?

Here is from paypal

https://www.paypal-community.com/t5/PayPal-Forward/PayPal-Response-to-SSL-3-0-Vulnerability-aka-POODLE/ba-p/891829

I am concerned about this as well. Have had 2 clients have payment problems today both with the same issue. Just wondering if it was related?

What kind of problems ? I don't think that this has anything to do with the fact that PayPal turned off SSLv3

I disabled SSLv3 in Apache on the server running WHMCS and all Paypal IPN messages stopped working. In Paypal on the IPN history page, they all said retrying. I turned SSLv3 back on in Apache and the messages started sending again.

I do not know if this is an issue with WHMCS or Paypal. Your mileage may vary, but that is my experience so far.

I disabled SSLv3 in Apache on the server running WHMCS and all Paypal IPN messages stopped working. In Paypal on the IPN history page, they all said retrying. I turned SSLv3 back on in Apache and the messages started sending again.

 

I do not know if this is an issue with WHMCS or Paypal. Your mileage may vary, but that is my experience so far.

Must be coincidence and is more likely because of the web server restarting or something. We disabled SSLv3 on Apache and have had no problems with PayPal after making this change.

It's entirely possible that it's coincidence, I am going to try again and see if the IPN messages queue up or not.

Edit:

As soon as I disabled SSLv3, the IPN messages start queuing up with a status of "Retrying".

It's entirely possible that it's coincidence, I am going to try again and see if the IPN messages queue up or not.

 

Edit:

As soon as I disabled SSLv3, the IPN messages start queuing up with a status of "Retrying".

We have the same issue on our vanilla WHM server. If SSLv3 is disabled in Apache, PayPal IPNs no longer reach the server... I added debug code to the IPN script on the server and it never gets requested by PayPal with SSLv3 off. Our server only supports TLS 1.0 (not 1.1 or 1.2) and I am wondering if this might be the culprit.

I can confirm this happen as well with NGINX.

when SSLv3 is disabled, payment gateways callbacks (including PayPal) are not working!

have you tried running this https://www.ssllabs.com/ssltest/analyze.html

have you tried running this https://www.ssllabs.com/ssltest/analyze.html

the WHMCS bug/issue, has nothing to do with the analysis.

and obviously, the analysis recommends to turn SSLv3 off...

We're getting the exact same issue our end. Disabling SSL3 and Paypal IPN's stop hitting our server. Any idea if WHMCS is looking into this ?

We're getting the exact same issue our end. Disabling SSL3 and Paypal IPN's stop hitting our server. Any idea if WHMCS is looking into this ?

I've reported to them.

for now it seems as they don't consider this a bug...

Hello,

I addressed this in the bug report thread:

http://forum.whmcs.com/showthread.php?94494-Disabling-SSL3-in-Apache-prevents-Paypal-IPN-Callback

Have any of you contacted Paypal about the fact that their IPN server can't connect to your server when you disable SSLv3 on your webserver?

Nate

Nate, No need to contact Paypal, they have already said they are removing sslve

I guess what we need to know is this defined

curl_setopt($ch, CURLOPT_SSLVERSION, 3); in the paypal module?

- - - Updated - - -

Ok Nate, just read your other post about it auto negotiating, so my question is answered.

Hello,

 

I addressed this in the bug report thread:

 

http://forum.whmcs.com/showthread.php?94494-Disabling-SSL3-in-Apache-prevents-Paypal-IPN-Callback

 

Have any of you contacted Paypal about the fact that their IPN server can't connect to your server when you disable SSLv3 on your webserver?

 

Nate

This also happens with other Payment gateways (not only PayPal)!

From support ticket:

Unfortunately at this time we require SSLv3 to be enabled.

MTK,

Was that response from WHMCS or Paypal? If WHMCS I would like to follow up and make sure you are provided the correct information. If that is the case, please PM me the ticket ID and I will follow up personally.

Nate C

MTK,

 

Was that response from WHMCS or Paypal? If WHMCS I would like to follow up and make sure you are provided the correct information. If that is the case, please PM me the ticket ID and I will follow up personally.

 

Nate C

yep, this was a WHMCS reply - ID sent to you by PM.

In case anyone is interested or is (for any reason) using the aWHMCS, this affects the app as well:

Turn SSLv3 OFF, and the app cannot login.

Turn SSLv3 ON and login works again.

We have also had IPN issues over the past few days after disabling SSLv3. However, it seems to only be affecting Asian clients

--- Deleted ---

as simple as adding one line:

http://stackoverflow.com/a/26380523

mtk,

Our callback file that handles paypal's IPN request and then does the handshake does not specify SSLv3 anywhere in it. Instead it autonegotiates which protocal and cipher list to use asking for the most secure and then moving back down.

The fix you link to only applies if you were hardcoding sslv3. To quote:

The version of PayPal API we are using hard codes CURLOPT_SSLVERSION to 3.

 

Our fix is to insert this before any PayPal calls.

 

PPHttpConfig::$DEFAULT_CURL_OPTS[CURLOPT_SSLVERSION] = 4;

I am afraid that your link is without relevance to what is actually happening.

If I were in our tech support department here is what I would do:

1) Get your specific libcurl version, php version, and cipher lists.

2) Upload a sample file that attempts to connect to the paypal server to see if you can do a SSL handshake, using the same curl options the code does. Here it is:

<?php

$url = "https://www.paypal.com/cgi-bin/webscr";

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, '');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 100);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_USERAGENT, 'WHMCS V' . '5.3.10');
$reply = curl_exec($ch);
if($errno = curl_errno($ch)) {
   $error_message = curl_strerror($errno);
   echo "cURL error ({$errno}):\n {$error_message}";
}
var_dump($reply);
curl_close($ch);

Run that and see if you get an error, here is what I get on my devbox:

[nate@nate ~]$ php t1.php

string(26) "\000\000\000\000\000\000\000\000\000��\000\000\000\000\000\000\000\000\000"

As you can see I connected to the paypal api server and got a reply. (not much there since I did not post anything, but if there was a curl error where a change like you recommend might have been needed, you would see a specific curl error w/a number and a message.

If you are getting a curl error there, please reply with the details of your libcurl, who provided it / compiled it, etc. Then we might have something to work with.

Nate C

Same issue here, and the problem IS WHMCS. I have another IPN endpoint on same machine ( different web app ) and it can negotiate the IPN callback just fine. Please recognize that this is NOT PayPal. Please take this seriously and quit telling everyone it is a PayPal problem.

Let Matt know about this and I am sure it will get fixed.

Thanks.

- - - Updated - - -

Nate,

I get this from the test script...

# php curltest.php

string(26) "??"

Yabdab,

You got a reply, not a curl error, this shows the code is able to make a SSL connection to the paypal server. Because the code did not send anything to the paypal server, its not going to respond with a detailed message.

Can you show me an access_log entry showing Paypal connected to the WHMCS callback file but nothing was logged in the transaction log then our support team can investigate further? If you can't see the connection in your access_log, then you know its paypal not making a valid SSL connection and that is the root of your problem.

Nate C

I am now seeing several "IPN Handshake Invalid" errors in my Gateway Logs when PayPal connects. Data is sent in IPN and logged.