PayPal Error (35) error:1408F10B SSL3_GET_RECORD:wrong version number

mprough:

PP tech support told me it's only a 24 hr reprieve
That wouldn't surprise me.

thank you

I've done some quick and dirty testing using wireshark to analyze the ssl handshake.

the results seem to suggest that these 3 scenarios are all similar
eg
Using
curl_setopt($ch, CURLOPT_SSLVERSION, 1);
curl_setopt($ch, CURLOPT_SSLVERSION, 4);
or in fact removing the curl_setopt($ch, CURLOPT_SSLVERSION, n); line completely
will force version negotiation and curl will then use TLS

It should be noted that php documentation is pretty poor on this. Suggesting that only 2 and 3 are valid options for CURLOPT_SSLVERSION but that given no version php will negotiate for the most recent version e.g. tls v1.2

As has been noted, paypal seems to have re added ssl v3 to their main live endpoint, while their sandbox is blocking ssl v3.
This maybe because they gave no notice, and have had mega complaints. It's still likely they will turn off ssl v3 on the live endpoints soon.

At this point, the advice DrByte posted in the release announcements should still be followed:
http://www.zen-cart.com/showthread.php?214916-Important-announcement-about-POODLE-and-payment-security

We will of course update that based on any further information.

To add a point of clarity, for those technically-minded, here are currently-valid SSL/TLS versions, listed from most-secure to least-secure:

Best to worst:
TLS 1.2 (best choice today)
TLS 1.1
TLS 1.0
SSL 3.0 (has the POODLE vulnerability)
SSL 2.0 (generally not recommended, and typically not even available in modern webservers)
SSL 1 (obsolete, no longer offered)

So, what wilt and I have been investigating is the net impact against performance based on the code changes I've been posting about.

And, so reading between the lines from wilt's post above, what we're seeing is that if one sets CURLOPT_SSLVERSION to 2 or 3, it will try SSL 2.0 or SSL 3.0, respectively, but if one comments-out the CURLOPT_SSLVERSION then the best TLS (or SSL if no TLS versions can be negotiated) will be selected.

(Admittedly we've also confirmed that setting CURLOPT_SSLVERSION to 1 does cause it to jump to autonegotiating a TLS version, but we'd like to do more research before recommending a specific value, since specifying a value like 5 or higher actually causes errors.)

Hope that helps answer questions for those who are curious.

Further, PayPal has posted today that they will (shortly) fully remove SSLv3 support from their servers ... so commenting-out the CURLOPT_SSLVERSION will be necessary ASAP.

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

We have also turned off SSl v3 support to the forum. This really shouldn't affect your experience in the forum, as content is negotiated via your browser.

I also use paypal payments standard. I just tested my site, and made a purchase with paypal and made a purchase with authorize.net credit card, and everything is working fine. Do you know why I would not be affected? Is it because I am using website payments standard?

What fix should people with paypal payments standard do? And we should do it even though there is no error??

WiccanWitch420:

I also use paypal payments standard. I just tested my site, and made a purchase with paypal and made a purchase with authorize.net credit card, and everything is working fine. Do you know why I would not be affected? Is it because I am using website payments standard?

What fix should people with paypal payments standard do? And we should do it even though there is no error??
Yes, make the change anyway. PayPal will be re-imposing the change they backed-out earlier today.

DrByte:

Yes, make the change anyway. PayPal will be re-imposing the change they backed-out earlier today.

But earlier today when everyone's site was not working with it, mine was. So i just want to clarify that since I only use website payments standard, that i need to do it, because i dont think it affects me. And if i need to do something , what do i need to do for the web standard?

While Zen Cart's implementation of PayPal Standard is not directly affected by this, I strongly believe you SHOULD STILL APPLY THE CHANGE, as it helps keep your site future-proofed and therefore more secure.

DrByte:

Today's PayPal issue has nothing whatsoever to do with what browser is being used.

Still reading through the thread; however, one individual that has reached out to me and spoken with their host has indicated that the host has disabled IE from reaching the site. If in fact it is not specifically browser related it would be good to let the host's know that.. Sorry, it would be good for the host's to not respond as if it is specifically a specific browser related issue...

mc12345678:

DrByte:

Today's PayPal issue has nothing whatsoever to do with what browser is being used.
Still reading through the thread; however, one individual that has reached out to me and spoken with their host has indicated that the host has disabled IE from reaching the site. If in fact it is not specifically browser related it would be good to let the host's know that.. Sorry, it would be good for the host's to not respond as if it is specifically a specific browser related issue...
I repeat. Today's PayPal issue has nothing to do with what browser is used. ALL of the PayPal communications discussed here are done via CURL (where CURL is the "browser" that PHP is using to connect to PayPal to broker the payment on behalf of the customer in-real-time). So it doesn't matter what browser you or your customer is using as far as making these PayPal transactions within your Zen Cart store.

As for other ways that SSL might affect hosts and sites, that's a completely separate topic, and should be discussed with hosting companies in their support tickets.
If a shopowner wants their SSL on their website to be "most compatible" with all browsers, they need to ensure that their hosting company and/or server administrator is indeed using the latest versions of applications on the server, including webserver and encryption and ssl and so on ... ie: be current. All of that is entirely unrelated to this PayPal issue today and unrelated to any configurations one can do to the Zen Cart software itself.

I also use standard and haven't seemed to notice any issues, however (might be coincidence) but today I'm noticing more people arriving at checkout confirmation but not completing checkout, therefore I have commented out the line as recommended. I will post back if I notice any negative impact.

DrByte:

Hope that helps answer questions for those who are curious.

Perfect. Thanks guys. I was planning on using wireshark over the weekend to see exactly what was going on with the various options/settings myself. You've saved me a lot of time :)

ZenCart really is the best. Not one of the other ecommerce forums I frequent come close to the speed and detail provided regarding this issue. (I suspect that's why PayPal have given a temporary reprieve - All of the other eCommerce systems are still looking for a solution, and I'll wager that none of them will provide the 'techie' info that you have.

Supurb!!

Cheers
RodG

RodG:

Perfect. Thanks guys. I was planning on using wireshark over the weekend to see exactly what was going on with the various options/settings myself. You've saved me a lot of time :)

ZenCart really is the best. Not one of the other ecommerce forums I frequent come close to the speed and detail provided regarding this issue. (I suspect that's why PayPal have given a temporary reprieve - All of the other eCommerce systems are still looking for a solution, and I'll wager that none of them will provide the 'techie' info that you have.

Supurb!!

Cheers
RodG

Yupp.. True dat!!!
nods in agreement:yes:

Man it's getting scary how sympatico you and I have been as of late.. :laugh:

TNX guys.

Authorize.net implemented the SSLv3 checks yesterday and the fix worked like a charm.

I wonder if this file needs to be changed in the current Download version of ZenCart? It still says "3" on the CURLOPT_SSLVERSION. I started getting errors today. Found this thread. Changed it to 4. I hope that fixes it.

Rather than hardcoding 4, the recommended fix is to comment out the SSLVERSION, as noted in post 1 of this thread: http://www.zen-cart.com/showthread.php?214916-Important-announcement-about-POODLE-and-payment-security

Ok, thanks. I'll do that.

Is anyone else getting errors like; (6) name lookup timed out or other similar timeout errors with Paypal Pro (paypaldp)?

Started with some sites about 24 hours ago.