POODLE and Paypal position

[s_p_ike]

Hello, when POODLE stuff was published here, I translated the official message here and published it in our forum (Zen Cart Italy) and made the fix for some site I manage.
A couple of weeks ago, Paypal (Italy) sent out a communication about POODLE. I got one of these, from the account manager of Paypal for that site. I pointed out 'our' solution was already in place and asked why tey were contacting us (saying that we were using SSL3). Tha account replied saying he asked to their tech and they suggested not to let php negotiate the protocol but to force using TLS.
I asked if this was official position of Paypal since it seemed to me that they previously 'accepted' to let php negotiate for the protocol to be a correct solution aswell.
No more answer, then, yesterday, I got in touch with another account (the first one is on vacation or whatelse) who pointed me to DrByte post here. There has been no way to have an answer why the former account manager told me that our official solution was not enough reliable.
So now, I'd just like to know if there are any side effects not to let php negotiate the protocol but to force the use of TLS.

Thank you

[lhungil]

Auto-negotiate is really the best option. This way the receiving server can tell your client (cURL) which versions and cipher suites it requires and prefers.

Forcing the use of specific versions or cipher suites would require additional management time. One would need to adjust each time third party companies change the versions and cipher suites their servers accept (and third parties are not always good at disclosing this information).

Another negative effect is your application would always be using only the version and cipher suites specified... So when a new version of TLS (or newer cipher suites) are adopted, your application would continue using the older ones only... The same holds true down the road, when TLSv1 or a cipher suite is deprecated / disallowed...

I'm sure there are some other good reasons, but these are the ones which stick out in my mind.


If you really want to go down the rabbit hole, take a look at CURLOPT_SSL_CIPHER_LIST and CURLOPT_SSL_VERSION. If you are on a more recently complied version of PHP+cURL, additional TLS options can be passed via curl_setopt.

[DrByte]

When I was speaking to PayPal tech staff I specifically asked if allowing auto-negotiate would be acceptable, instead of specifying TLS1 now when it's actually much older than TLS 1.1 or 1.2, etc. They said auto-negotiate is just fine.

And I tend to agree. That then permits Zen Cart to operate independently of whatever PayPal's latest security protocol is, and puts the onus on the server admin (hosting company) to properly configure the server's security protocols.

That said, if you have a specific reason for not trusting auto-negotiate (ie: you can't properly secure your server) then you can hard-code CURL_SSLVERSION_TLSv1_0 if your PHP version supports it. But if your PHP version is old then your PHP won't know what that means, and that'll stuff it back into autonegotiate mode or something worse like throwing errors that cause payments to totally fail.

It's open source code ... you can do what you like. But the developers make a strong effort to do what works best for the best security and the broadest combination of common hosting environments, including communicating with the payment companies to cooperate the best they can.

[s_p_ike]

Thank you lhungil an d Dr. I agree with both of you of course. I was just worried about the answer I got from Paypal account. But now I just received other confirms from the same account who told, now, that auto negotiate is fine.
I obviously was confident on official solution from Zen Cart team and I too thought that autonegotiate was the best option for the reasons stated by lhungil, but if a paypal tech tells you otherwise, doubts just start rising.

[s_p_ike]

Hello, I just tested the patch over a 1.5.0 (using sandbox account of course), but it didn't succeed. I always got a timeout error: (28) Operation timed out after 60001 milliseconds with 0 bytes received (in logs, since in browser it produced a 500 error at the url ipn_main_handler.php).
So I overwrote paypal files using ones from 1.5.3 and then it started working without problems.

I do not know if 1.5.1 has the same issue, nor if it is just a problem related to sandbox environment.

[mc12345678]

The sandbox uri for ZC changed between ZC versions, yet another reason to either upgrade or pay attention to forum issues. The ipn_handler.php file in the store's root may also need to be updated to properly handle/address the updated paypal files... I don't recall the change history of it...