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.

[EdP]

@Paul_Holden Based on the document below, 2022.1 uses OpenSSL 3.0. I'm not able to determine the version used in 2020.4. 

 Alteryx’s Response to CVE-2022-3602 and CVE-2022-3786 (Spooky SSL)

[Paul_Holden]

@EdP thanks. I'm still thinking that this is an issue with our Netscaler but I'm struggling to find the key that opens the lock with our networking team.

[Paul_Holden]

@EdP 

We have done some more work on this and it seems almost certain that the issue is that the Netscaler Load-balancer that sits in front of the application servers is set to deny all SSL renegotiation.

I have asked if this can be changed to deny only INSECURE renegotiation which I believe might resolve the issue.

However my Netsec team have come back and asked why Alteryx uses SSL renegotiation at all. They are saying that it is fundamentally insecure (even the "secure" version) to the extent that it has been removed from TLS 1.3

At this point they are refusing to change the NS-LB configuration without further justification and/or confirmation that Alteryx cannot be re-configured to not use renegotiation.

They are also asking why this issue has only just come up when TLS renegotiation issues and fixes are now many years old, e.g. CVE-2009-3555 which is 2009

Is there a fundamental flaw in OpenSSL that means that no renegotiation is a vulnerable configuration? If so I'm struggling to find a document that I can point to which is newer than the comments on CVE-2009-3555 and RFC5746 which are sufficiently old that I cannot explain to my Netsec team why the 2020 version of Alteryx did not suffer this same issue.

Anyone have anything that I can go back with on this. Comment by @GloriousWater that secure should be better that insecure is unfortunately not carrying much weight with them as they are saying that any is worse than none?

Regards,

Paul

[GloriousWater]

Hi @Paul_Holden 

My comment about deny only insecure was more safe was just parroting one of our guys from the IT dept. I believe it was just a quick thought train, that a double handshake should be better than one, but from a quick google this opens a vulnerability for DDOSing the server. 

I believe you should be able to use the python tool to query your server instead of the download tool as the python tool should (i believe it should work but i have not tested it) allow you to disable the renegotiation as you essentially write the code for your request rather than use the UI of the download tool that is a bit more hard coded. 

I hope you find a solution.

[Paul_Holden]

@GloriousWater 

Thanks for the comments. Right now I'm trying to get some more information from the Alteryx devs as to why they activated renegotiation in the latest version. Whether that was a mistake or whether secure reneg is actually better than no reneg in the specific circumstances of the download tool.

If it is then I can get our Netsec team to allow it on the endpoint(s) that Alteryx is hitting.

If it isn't then I'm hoping we can get a fix from Alteryx to allow us to switch off reneg for the download tool.

The python tool is fine if you have python dev resource available. Unfortunately in this case, and I can't believe we are alone in this, the USP for Alteryx was that it was a "no code" solution and that was the basis on which it was chosen. Turning around to the business and telling them they now need developer time to make the workflow functional again is not a good look.

[EdP]

Server 2022.3 has been released and includes a configuration file to provide a means to adjust security checks performed by the Download Tool on a site-by-site basis. This replaces any previous workarounds.

Please see:  https://help.alteryx.com/20223/designer/peer-validation-allow-list

[Paul_Holden]

@EdP thank you for the heads up.

[jason_scarlett]

@EdP 

This worked for us after upgrading to 2022.3.

[Paul_Holden]

@EdP 

I need to see if I can agree a maintenance window for another upgrade to Alteryx.

I'm still not convinced that this is going to resolve the issue for us since the problem is NOT that the remote system does not support secure renegotiation it is that the remote system does not support renegotiation at all. So far all fixes supplied by the Alteryx devs have only tried to address the legacy vs secure renegotiation unfortunately.

[glenebb]

I can see the TLS Peer validation bypass in my results window but i am still receiving the SSL connect error