Important Update for ArcGIS and TLS

Esri is committed to providing strong security for the ArcGIS platform by using the latest industry standards and best practices for security protocols. To meet these industry expectations, we are making an important update to ArcGIS Online on April 16, 2019 that is likely to affect most ArcGIS software and custom solutions. With this change, we are enforcing the use of TLS (Transport Layer Security) version 1.2 only and will remove support for earlier TLS versions 1.0 and 1.1.

More details about Esri’s support for TLS, including patches and instructions for updating software, can be found by visiting support.esri.com/en/tls.

Who is affected? Users of most ArcGIS software or custom solutions using Esri technology may be affected by this planned update to TLS protocol v1.2.

What do I need to do now? Go to the Esri TLS Support page for more information and specific actions you may need to take in advance of this update.

Was this added to AGOL to help organizations prepare for the update of AGOL in Feb.2019 when http access will no longer be allowed?

Would checking the box for Allow access to the organization through https only simulate the change that ESRI will be making to AGOL, so ArcMap 10.5.1 clients without the patch would be unable to publish up to AGOL?

In February we'll be changing ArcGIS Online so that HTTPS connections can only be made via TLS 1.2. Currently ArcGIS Online supports TLSv1.0, TLSv1.1, and TLSv1.2.

Later this year (Q4 expected) we'll be updating ArcGIS Online to require HTTPS and disabling plaintext HTTP.

You're correct that this warning was put in place to gently nudge users toward HTTPS so that they have time to test workflows and generally become accustomed.

Regarding your question:

No - checking this box would just force you to use HTTPS when working with your ORG. The patches for ArcGIS Desktop are specifically to support TLS 1.2. If you checked this box, at this point your users wouldn't see a failure because they'll just use older versions of TLS to connect to ArcGIS Online. It wouldn't be until the 20th of February that they'd experience an issue when connecting to ArcGIS Online using the Add Data button.

We'll be releasing a list of TLS 1.2 only endpoints very soon (with instructions) with which users can test the experience.

I'm wondering if ESRI is still planning to update ArcGIS Online to require HTTPS and disable plain text HTTP this year (you said Q4 expected in your January reply) or if this has been pushed back. Will we receive email communications from ESRI warning us of any impending HTTP disabling like the TLS changes? I'd like to give my users a heads up and check their content, ideally with a timeframe in mind but I can't find any other dates for the ESRI HTTPS switch in my searching.

Good question, and sure thing. When you're working with a stand-alone (unfederated) instance of ArcGIS Server, under the sharing tab, you'll see where you can associate the GIS Server with ArcGIS Online or some other Portal, like this:

On a federated instance, this dialog looks like this:

In either case, you can update sharing details for a service from manager.

If you're working with a stand alone instance of ArcGIS Server, once you've signed into the portal, you can click the little sharing icon next to the secure service 'lock' icon, and share a reference to the service to a group:

If your GIS Server is already federated with a Portal, you don't need to sign in because the security model is owned by the Portal, and if you've logged into ArcGIS Server Manager, you're also logged into the Portal.

In essence, the TLS issues a user may see in ArcGIS Enterprise come down to features that are used when the software acts as a CLIENT, not as a SERVER. ArcGIS Enterprise as a SERVER has supported TLS for some time. It's various client components that can have TLS related issues. An example - the ArcGIS Server print service. When using the print service, ArcGIS Server acts as as client to some GIS Server (quite often that server is itself). The print service makes an export map request to the server, and uses the response to create printed output, and places the output in a virtual directory. At that point, the browser client makes a request to ArcGIS Server to pull the output down.

Maybe I'm misunderstanding this, but It looks like in order to use some capabilities, ArcMap, for example, has to support TLS 1.2. ESRI will release such a version in "first half of 2019". But the requirement for TLS 1.2 starts in February, likely before a supporting version of ArcMap is available. So we have to patch the latest version available. The timing of the product releases and TLS 1.2 requirement seem strange.

I have an application that is build with ArcGIS Runtime SDK for .NET v100.2 and there is no mention of the impact of this. There have been a few bugs that have limited us to that version until the next release of the SDK.

The only mention of older 100.x versions is in regards to their support status, this does not help with TLS impact information.

The text on 100.4 basically applies to all 100.x releases of the ArcGIS Runtime SDK for .NET. With respect to .NET, the TLS version used can be defined by the .NET Framework, application logic, or operating system. Best practice is the operating system defines the version: https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls What this means is as long as the machine/device on which the .NET Runtime app is running is configured to use TLS 1.2 or greater, the client will use it. To confirm with the app in question, you can review the network traffic to see which TLS version is being used.

Thanks for reporting that! We've checked the service and it should be responding correctly now. Please post again or submit a support case if there are any further access problems with the service or questions about the TLS changes.

My org is having server issues, so we are stopping all servers. I have stopped services in development and tried to open ArcGIS Server (AGS) Manager and I receive the following error which I was not expecting:

Http/1.1 Service Unavailable

Would this indicate that my AGS environment is running with http protocol using TLS1.1 which will be going away?