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

PayPal Express has been working well up until we received this error.

Dear store owner,
An error occurred when attempting to initiate a PayPal Express Checkout transaction. As a courtesy, only the error "number" was shown to your customer. The details of the error are shown below.



(35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Zen Cart message: An error occurred when we tried to contact the payment processor. Please try again, select an alternate payment method, or contact the store owner for assistance.

Problem occurred while customer was attempting checkout with PayPal
Express Checkout.

We are ZC v1.5.1

Thanks for any insight you can provide.

Phil and Pam
www.heirloomstocherish.com

Two carts just started throwing errors with PayPal Pro.

First error is error:14094410:SSL routines:SSL3_READ_BYTES:sslv3

Second is error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
version number

I found a post here: http://stackoverflow.com/questions/2...r-paypal-maybe

It says they believe PayPal has changed - and the fix someone has discover is this:
curl_setopt($handle, CURLOPT_SSLVERSION, 4);

Has anyone heard anything?

Just found this: https://www.ssllabs.com/ssltest/anal...ypal.com%2Fnvp

Getting this too. Same ZC version 1.5.1

Looks like a sudden change made by Paypal, some discussion here: http://stackoverflow.com/questions/2...r-paypal-maybe

Quote:

---

Originally Posted by Phil Soth

PayPal Express has been working well up until we received this error.

Dear store owner,
An error occurred when attempting to initiate a PayPal Express Checkout transaction. As a courtesy, only the error "number" was shown to your customer. The details of the error are shown below.



(35) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Zen Cart message: An error occurred when we tried to contact the payment processor. Please try again, select an alternate payment method, or contact the store owner for assistance.

Problem occurred while customer was attempting checkout with PayPal
Express Checkout.

We are ZC v1.5.1

Thanks for any insight you can provide.

Phil and Pam
www.heirloomstocherish.com

---

Sounds like this (posted about 8hrs ago)
http://stackoverflow.com/questions/2...r-paypal-maybe

I'm not sure this will be of any help though. Point is, you're not alone.

Cheers
RodG

PS: Shoot. you just beat me to it. Exact same link. LOL

Yes, the immediate solution is to change the CURLOPT_SSLVERSION from 3 to 4 ... or comment-out the line entirely.

Quote:

---

Originally Posted by RodG

Shoot. you just beat me to it. Exact same link. LOL

Cheers
RodG

---

Hehe, as you say--good to know we're all aware of it. Hopefully the thread catches the attention of the right people, assuming any ZC updates are needed.
The stackoverflow thread links to the Paypal SDK github discussion, which has been updated to closed/resolved.

Add me to the list as well. Both pro and express checkouts affected. Orders bouncing all morning.

Quote:

---

Originally Posted by DrByte

Yes, the immediate solution is to change the CURLOPT_SSLVERSION from 3 to 4 ... or comment-out the line entirely.

---

In the Paypal github discussion (https://github.com/paypal/rest-api-sdk-php/pull/127) the "official" recommendation appears to be changing CURLOPT_SSLVERSION

I have no expertise here, just reading the posts; happy to follow the official ZC recommendation.
Changes to: "/includes/modules/payment/paypal/paypal_curl.php" correct?

I found the string to change, fortunately its easy:

/web/content/includes/modules/payment/paypal/paypal_curl.php
Line #58 : CURLOPT_SSLVERSION => 3,

Change to CURLOPT_SSLVERSION => 4,

It works ...for now. Thanks for the notice paypal...

Quote:

---

Originally Posted by nightdesigns

I found the string to change, fortunately its easy:

/web/content/includes/modules/payment/paypal/paypal_curl.php
Line #58 : CURLOPT_SSLVERSION => 3,

Change to CURLOPT_SSLVERSION => 4,

It works ...for now. Thanks paypal

---

Good to hear it worked for you. It was a sudden change, but it's related to a new, serious bug with ssl: "Poodle"

I know it was an urgent fix, but some announcement would have been nice. They're usually pretty good about letting us know about other changes.

So glad I saw this thread today! I was pulling my hair trying to figure out why the error was being thrown. Made the edit to CURLOPT_SSLVERSION from 3 to 4 and that seems to have done the trick! Yea! Thanks PayPal for letting us know!

http://www.zen-cart.com/showthread.p...56#post1261356

Quote:

---

Originally Posted by DrByte

http://www.zen-cart.com/showthread.p...56#post1261356

---

Thanks for dealing with this so quickly!

Please see official recommendation from Zen Cart Team: http://www.zen-cart.com/showthread.p...yment-security

All the carts I have been checking on are getting this error too. I tried the fix on one cart and 5 minutes later an order came through so the fix worked. Will this be the permanent fix or should we expect to need to update the paypal express module in the near future?

Quote:

---

Originally Posted by buildingblocks

Will this be the permanent fix or should we expect to need to update the paypal express module in the near future?

---

For now this is a known and verified fix, and worth rolling out to all your sites immediately.
However, it's early days on this we are indeed researching whether there are even better fixes available. But that's NO reason to not apply the known fix NOW.

Time will tell whether there is an even better fix. We will post in the Release Announcements if there is an updated better solution.

Is it only with IE? I was under the impression that Chrome and Firefox work and do not have the vulnerability.

Quote:

---

Originally Posted by OLD MAN

Is it only with IE? I was under the impression that Chrome and Firefox work and do not have the vulnerability.

---

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

I take it this doesn't affect paypal website payments standard? I haven't had any issues today... ?

I would just like to voice a sincere Thank You to the folks who help make this a true Community. Your willingness to help, and the quickness and professionalism you show is profound. Outstanding job! You all may not be told often enough, but you are truly appreciated.

Quote:

---

Originally Posted by philip937

I take it this doesn't affect paypal website payments standard? I haven't had any issues today... ?

---

If you update paypal_curl.php as advised, you shouldn't have any issues with Standard. I WOULD recommend applying the fix even if you haven't seen any problems yet.

I've made the suggested change. I'll switch back if I notice any issues using the setting on standard.

Ps - the only reason I knew about the issue was because I received an email from Numinix. They are suggesting changing value from 3 to 1..

I think I'll take my advice from here.

Yeah, I sent them a link to the forum. I think the change happened at about 12:30 pm EST. I'm still writing the newsletter (between uploading fixes) for my email list!

I called PayPal this morning, as soon as I received 7 PayPal Express Checkout errors, and that is how I found out about this. However, PayPal told me to change from v3 to v1. So I was wondering, would it be okay to change from it to v1…or is the recommended suggestion still to change from v3 to v4? I'm not sure which to do now. Thanks for any suggestions. :)

Quote:

---

Originally Posted by DrByte

If you update paypal_curl.php as advised, you shouldn't have any issues with Standard. I WOULD recommend applying the fix even if you haven't seen any problems yet.

---

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??

Quote:

---

Originally Posted by oc-flyfish

I called PayPal this morning, as soon as I received 7 PayPal Express Checkout errors, and that is how I found out about this. However, PayPal told me to change from v3 to v1. So I was wondering, would it be okay to change from it to v1…or is the recommended suggestion still to change from v3 to v4? I'm not sure which to do now. Thanks for any suggestions. :)

---

Just personal opinion, but if your host supports V4 then that will probably be the preferred option. Better to move forward than backward I reckon.

Cheers
Rod

Quote:

---

Originally Posted by philip937

I've made the suggested change. I'll switch back if I notice any issues using the setting on standard.

Ps - the only reason I knew about the issue was because I received an email from Numinix. They are suggesting changing value from 3 to 1..

I think I'll take my advice from here.

---

Quote:

---

Originally Posted by oc-flyfish

I called PayPal this morning, as soon as I received 7 PayPal Express Checkout errors, and that is how I found out about this. However, PayPal told me to change from v3 to v1. So I was wondering, would it be okay to change from it to v1…or is the recommended suggestion still to change from v3 to v4? I'm not sure which to do now. Thanks for any suggestions. :)

---

I WOULD NOT CHANGE IT TO v1.

SSL v3 IS NOT THE SAME AS TLS v1

THERE IS A LOT OF CONFUSION IN THE PHP DOCUMENTATION and testing various approaches yields confusing results.

If you're uncomfortable with setting it to v4 (which technically doesn't yet exist), then simply comment-out the line, so that the version is auto-negotiated with the server. (Which is really the desired result anyway. The whole reason for specifying v3 initially was that v2 was deemed insecure but was the assumed default, but that has changed in modern PHP versions.)

The Dr has spoken! Cheers

Wow! I'm so glad I asked!!!! Thank you so much DrByte!! PayPal has really outdone themselves this time! Ha! Grrrrr....

What about USPS?

I have made the change to 4 and everything is back on track!

To underscore earlier praises, thank you so much for the quick and accurate response to this problem.

BTW, I also called PayPal this morning, and the tech told me outright that it was not a PayPal problem, but a selling platform problem, and that if I was paying for a website ( as opposed to using Zen Cart ), this would probably have been resolved before I had seen it appear. I felt dutifully spanked for my transgression, and slinked off into the sunset....

Anyway, thanks again - - - -you people are exceptional!

Phil
Heirlooms To Cherish

Quote:

---

Originally Posted by mprough

What about USPS?

---

For USPS, if you're getting the same error, simply comment-out the CURLOPT_SSLVERSION line. I posted similarly in the Release Announcement earlier. I'll update it with more specific wording shortly.

(That said, I recall a time I was working with Ajeh where it actually *needed* v3 specified ... so change according to your server requirements, ie: whatever stops throwing any errors.)

Quote:

---

Originally Posted by Phil Soth

if I was paying for a website ( as opposed to using Zen Cart ), this would probably have been resolved before I had seen it appear.

---

That's like the dumbest a$$ed remark the tech could have made.. I DO HOPE this foolish person tells one of their larger corporate clients who ALSO do not have any kind of "paying website" (because they have a tech dept that built their site) this SAME message..

**SMH**

Quote:

---

Originally Posted by DrByte

I WOULD NOT CHANGE IT TO v1.

SSL v3 IS NOT THE SAME AS TLS v1

THERE IS A LOT OF CONFUSION IN THE PHP DOCUMENTATION and testing various approaches yields confusing results.

If you're uncomfortable with setting it to v4 (which technically doesn't yet exist), then simply comment-out the line, so that the version is auto-negotiated with the server. (Which is really the desired result anyway. The whole reason for specifying v3 initially was that v2 was deemed insecure but was the assumed default, but that has changed in modern PHP versions.)

---

FYI, I've changed our recommendation to simply comment out the CURLOPT_SSLVERSION instead of setting it to v4.

It's also worth noting that it appears as though PayPal may have recanted their aggressive block of all SSL3 connectivity to their live site, as connections are once again working fine (at this moment) using the original CURLOPT_SSLVERSION => 3 setting.

Quote:

---

Originally Posted by DivaVocals

That's like the dumbest a$$ed remark the tech could have made.. I DO HOPE this foolish person tells one of their larger corporate clients who ALSO do not have any kind of "paying website" (because they have a tech dept that built their site) this SAME message..

**SMH**

---

Seconding That /\ /\ /\

How does this apply to authorizenet_aim.php? Didn't notice a separate thread for it and do see

curl_setopt($ch, CURLOPT_SSLVERSION, 3);

at my 576...

What's the move??

Thanks a bunch,
John

Quote:

---

Originally Posted by bumba000

How does this apply to authorizenet_aim.php? Didn't notice a separate thread for it and do see

curl_setopt($ch, CURLOPT_SSLVERSION, 3);

at my 576...

What's the move??

Thanks a bunch,
John

---

IMO I'd leave it alone for now (I'm not seeing any errors with Authnet as-is right now), as even PayPal has apparently relaxed their initial hyper-protective rejection of all SSL3 connections. But if the same error pops up suddenly, simply comment out the line.

PP tech support told me it's only a 24 hr reprieve

Quote:

---

Originally Posted by 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.p...yment-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/...LE/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??

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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...

Quote:

---

Originally Posted by mc12345678

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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.p...yment-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.

PayPal must be messing with their API because that's when I started getting a whole new round of error messages too.

Quote:

---

Originally Posted by rcloke

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.

---

Did you make the changes suggested (see a post or two above your post)

None of my clients are reporting any issues if the specific lines are commented out.

Quote:

---

Originally Posted by delia

None of my clients are reporting any issues if the specific lines are commented out.

---

Ditto..