API Download Tool Error transferring data: SSL connect error

[lipster26]

Hello,

I'm getting Error transferring data: SSL connect error when using the Download tool to call to an API. I just upgraded to 2022.1. I reinstalled 2021.4 and it worked on that version. I've also verified the keys/client Id work on Postman. Any ideas what changed in the upgrade?

Thanks.

[EW]

I just had the same error with 2022.1.1.40869, but it worked upon re-running the workflow?  AMP is off.  Not sure why it would be intermittent.  Frustrating that updating to 2022.1 is causing problems with workflows that were working fine before I updated.  

[GloriousWater]

@EdP 

Hi, we just upgraded our server from 2021.2 to 2022.1 and we are experiencing this issue when using the downloadtool to connect to a specific external software service (it works for other places).
On 2021.2 designer it runs fine; but on 2022.1 designer and server we get the SSL Connect Error.
AMP is and was always disabled.

Can you please provide some steps on how to force access to less secure sites?

Regards GloriousWater

[GloriousWater]

@EdP 

Hi Ed. Thanks for providing the technical steps bypass the patch, it did allow the connection again, but as you said it is not a recommended solution as its on a server level.

Also; does this mean that previous versions of Alteryx < 2022.1 have been open to the vulnerability?

[EdP]

Hi @GloriousWater -

Please look back at my ‎09-13-2022 post for specifics about what was tightened in the 2022.1 Download Tool.  And please check release notes for 2022.3 Server (https://help.alteryx.com/release-notes) and the version-to-version Guide (https://help.alteryx.com/current/server/install-or-upgrade-server#upgrade-server) after 2022.3 Server releases for updates any updates on this issue and potentially more fine-grained workarounds.

[GloriousWater]

So after a lot of digging and googling, the solution to why my download tool was suddenly giving this error after upgrading to 2022.1, was because Alteryx from 2022.1 is attempting to renegotiate handshakes. Our software vendor is using NetScaler, which has the default setting of deny-all-reneg. Reaching out to our vendor confirmed this was the cause. After they updated the setting to deny-insecure the issue was resolved. 

https://github.com/Kong/insomnia/issues/4543

An argument to make this change to the settings would be that allowing renegotiation should be more secure.

Hope this can help someone else out there :)! Another alternative worth looking into if you cannot find a solution would be to use the python tool for the API calls instead of the download tool as you can control the variables. 

[Mispell]

Having an issue with this as well. The API call doesn't B64 the username and password. 

.

It comes back with 

Download (3) Error transferring data ****** Failure when receiving data from the peer

However, when I run the same call and change 'xml' to 'json' it works (it just doesn't give me all the nested fields, or I'd just use json (and I tried randomly as changing to json isn't in the documentation)

I can run both the the xml and json versions in Postman as both GET and a POST and successfuly retrieve data (except again the json is undocumented and doesn't give me all the data required)

[Adamyde]

👍

[Paul_Holden]

That CVE/RFC are many years old now.

I'm being told by our Network team that everything in place is/was already updated but I'm still getting this error.

I'm totally stuck at this point so if anyone has any ideas on what might work...

[Paul_Holden]

@GloriousWater have just seen your post about netscaler.

The end point I'm trying to hit is behind a netscaler LB but I'm being told that the setting that you quoted is only relevant if Alteryx is behind a netscaler.

Any idea if that is true, it seems a bit odd to me that it wouldn't need to be set correctly regardless of which end the netscaler is at?

[Paul_Holden]

@EdP 

Is it possible to get confirmation of what versions of OpenSSL are deployed with 22.1 vs 20.4 so that we can confirm exactly what changes have been implemented?

There is a lot of back and forth with my network team because the referenced RFC and CVE are so old and don't relate to the Nov 2022 OpenSSL bug which they assumed was what was fixed.