Crank Up Security With TLS 1.1
I recently bumped into a few clients who weren't sure about what was going on with this TLS 1.0 thing. So, I thought I would write a recap and collate the best resource available online, all in one post. Hopefully, this can help you communicate with your customers or stakeholders too.
❓ What's happening?
Salesforce is about to upgrade its servers and enforce the use of a new encryption protocol. Failure to changing to the same protocol on the client side will lead to service disruption.
📅 When is it happening?
Saturday, March the 4th 2017
Saturday, July the 22nd 2017 (cutover date recently postponed by Salesforce)
I've been made aware of customers entangled in technical debt pushing up to November 2017...
🔎 Where is this happening?
The risk of using the wrong encryption method exists in all areas of Salesforce making use of a network connection. A Visualforce page pulling some data from a custom object is not in scope. I have segmented these areas of concern into 4 categories:
Access to the application
Make sure that the browser you are using supports and is configured to use TLS 1.1. Validate that you are using the latest version of Salesforce1 on any mobile OS. Bespoke mobile apps must be adapted.
If you are using tools that communicate with Salesforce and have required you to use a setup program then, please validate with the vendor that they're not stuck on TLS 1.0. This includes Salesforce for Outlook, DataLoader, etc...
If you are integrating Salesforce with your ERP or any system in your IT landscape, make sure that the data flows are encrypted using TLS 1.1. Integration layers (ESB, EAI) are certainly up-to-date with the latest technology but what about the little Java application that was written 5 years ago by... "someone"?
Some AppExchange rely by-design on an external set of servers for various reasons. This is typically happening when an AppExchange requires capabilities not currently available on force.com or needs access to an external source of information. Some code, in Salesforce, is calling a server somewhere and they're having a chat. This "conversation" has to be encrypted using TLS 1.1.
You'll get the exact list of endpoints that you should validate in Salesforce's excellent article: "Salesforce disabling TLS 1.0". It's the reference on the topic!
🔨 How do I do it?
First, you should download and run my report (https://login.salesforce.com/packaging/installPackage.apexp?p0=04t0Y000000JwLn) to identify who, in your org, is still connecting with TLS 1.0. This will address point 1, 2 and most of point 3 (ESB using a connector will be spotted) above.
For the integration points, you should get a developer to trace the Apex classes making use of web services then reverse engineer them if, as I suspect, you too have lost the documentation.
For the AppExchange, list them and go one by to the vendor online specs. If you're lucky, you should get a nice TLS support statement. Even better, You can have a look at Rupert Barrow's list of the AppExchange known offenders (still locked on TLS 1.0).
If this is not enough, Salesforce, them again, have put together a great action plan: the "TLS 1.0 Disablement Readiness Checklist ".
📘 How can I learn more?
Salesforce's Infrastructure Security team provided information and tips to help ensure your org is ready for TLS 1.0 disablement on a recorded webinar:
- Explain how this change will impact Salesforce products, services, and developer tools
- Show you how to identify users still creating TLS 1.0 connections
- Highlight resources and best practices to help you prepare your Salesforce org and your users for this change
- Answer questions from the webinar audience
Below are the links to the recording and resources referenced in the session:
- Webinar Deck: http://bit.ly/TLSWebinarDeck
- Full Webinar Recording: http://bit.ly/TLSRecording
- Login History Demo: http://bit.ly/TLSDemo
Finally, as I was doing my research for this post I found this old course from the MIT and thought it would be a good idea to share as it's giving a good background on network encryption.
I hope you enjoyed this post. Don't hesitate to ping me on Twitter if you have any comment or question.