Esri / arcgis-cookbook

Chef cookbooks for ArcGIS
Apache License 2.0
290 stars 115 forks source link

Unable to Federate exclusively using TLS 1.3 #376

Closed tatornator12 closed 6 months ago

tatornator12 commented 7 months ago

Hey @cameronkroeker,

We've been running fine with our 11.x deployments using cinc-17.10.0 on RHEL8 for quite some time. We recently got a new request from our security team to enforce TLS 1.3 only at our Application Load Balancer. In doing some testing in our dev environment with that enforced, I noticed that the Federation recipe fails to federate any ArcGIS Servers. Turning on the debug logs produces the following error until it time's out completely:

DEBUG: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert protocol version

When I switch the ALB's security policy to the default (TLS 1.2), everything works fine. In some brief searching, I noticed that error pertains to something with Ruby....but I am no Ruby expert. I was curious if you or your team has come across that before? I was looking into updating the cinc client, but not sure if that could break anything else.

Thanks, Taylor

cameronkroeker commented 6 months ago

Hi @tatornator12,

Our team is also seeing same issue. The Net::HTTP client used by ArcGIS Chef cookbooks to send HTTPS request fails to connect to TLS v1.3 URLs when it runs using the ruby embedded in Chef\Cinc Client. However, the same test succeeds when it runs in standalone ruby 3.1.0.

We suspect this is because TLS 1.3 requires OpenSSL 1.1.1, but the Chef\Cinc clients 17/18 on Windows and Linux still use OpenSSL 1.0.2zg-fips.

Looks like Chef Server/Chef Infra Client does not yet fully support TLS v1.3:

https://github.com/chef/chef-server/issues/2348#issuecomment-804611399

Thanks, Cameron K.

tatornator12 commented 6 months ago

Thanks for having your team look into this!

We can get by for now with adding some logic to flip the switch on after deployment.