Salesforce will stop supporting the TLS 1.0 encryption protocol, world-wide on all instances, starting March 4, 2017. This change is easy to miss or ignore, however it’s impact will not be. Once Salesforce TLS 1.0 is disabled, mechanisms using this encryption will literally stop working unless you’ve done your due diligence.

 

What is TLS?

TLS stands for Transport Layer Security and it’s responsible for securing the communication between two endpoints in several ways:

  1. Encryption – the communication in transit is encrypted over the internet keeping the information private.
  2. Authentication – the two endpoints communicating can authenticate each other’s identity thereby having confidence they are communicating with the intended party.
  3. Integrity – allows for detection of data loss or a change to the data

As a side note, for a more robust review of encryption and understanding the basic principles of Cryptography, I would highly recommend “Cryptography Decrypted” by H.X. Mel and Doris Baker.

 

Why is TLS 1.0 being disabled?

TLS 1.0 has several well-known security vulnerabilities such as POODLE, BEAST, and cipher block chaining (CBC) attacks. Newer versions of TLS have been implemented differently to protect against current, and potentially future, vulnerabilities. In fact, many current browsers will now warn you if TLS 1.0 is in use. In addition, the PCI Security Standards Council now recommends against the use of TLS 1.0.

 

How can you prepare for Salesforce TLS 1.0 disablement?

Salesforce has released an excellent article detailing the various ways to test for and resolve TLS 1.0 issues. The main article is located at Salesforce TLS 1.0 disablement. In terms of areas to explore you’ll need to review the official Readiness Checklist located at Salesforce TLS 1.0 Disablement Readiness Checklist. This checklist walks you through the main areas of concerns that should be reviewed. This list includes:

  1. Browsers
  2. AppExchange products
  3. Inbound API integrations
  4. Outbound API integrations
  5. Java versions
  6. Development tools and the frameworks they leverage

However, your first stop to evaluating your Salesforce org should be to review the Login History by following these steps:

  1. Navigate to Setup and in the Quick Find box type “Login History”
  2. Click the “Login History” link
  3. Select your file type. I typically select “CSV File”
  4. Select your file contents. Make sure to choose “TLS 1.0 Logins Only”

 

Salesforce Login History

 

Once saved, open the “Login History” file to review the last six months of connection information.  This file contains a lot more information than the summary data you saw on the “Login History” page. Since we requested “TLS 1.0 Logins Only”, any records in this file are an indication that follow up or resolution is required. What’s great about this information is that it’s easy to pin down issues in that it details the Username, IP, Platform, Application, and Browser (among other fields). Incidentally, the “TLS Protocol” field is new as of Summer ’16. Using the filtering powers of Excel you can derive distinct lists of offending browsers in use, non-compliant AppExchange products, and outdated Java versions.

 

Moving forward

Knowing the issues around Salesforce TLS 1.0 are half the battle. Now comes the challenge. Every item on the “Login History” report needs to be addressed in some manner. Here is an approach for common issues

  1. Users connect using an outdated browser – contact those specific users and have them upgrade their browser (Firefox, Chrome, Safari, Internet Explorer) to a compliant version. See the links above that contain detailed information regarding the compliant versions. As an alternative, you could send an org wide email addressing this issue.
  2. AppExchange Products are connecting with TLS 1.0 – explore if there is an update or new release on the AppExchange that may resolve the Salesforce TLS 1.0 issue. If not, contact the vendor. They will be aware of this issue and may very well be working to resolve it. One that we see a lot is “Salesforce for Outlook”.
  3. Something specific is called out such as Java – It is most likely a non-compliant version of Java. This can also happen with other frameworks such as .Net, Python, and so on.

While the “Login History” is a solid start to determining your readiness, reviewing the Salesforce TLS 1.0 documentation on this matter is critical. Salesforce goes in-depth on all the nuances needed such as Apex call outs and how to test them, mobile applications, development tools, and other potentially impacted Salesforce products.  By being pro-active and addressing this issue prior to March 4, 2017 you can increase your chances of a smooth transition.

One final point to mention is that you can manually disable TLS 1.0, in either Production or Sandbox, to test the impact early. This is useful if you’ve already performed your mitigation steps and believe you’re ready for the change. Don’t wait until Salesforce automatically disables TLS 1.0. To manually activate this change, simply follow these step:

  1. Navigate to Setup and in the Quick Find box type “Critical Updates”
  2. Click the “Critical Updates” link
  3. List of available Critical Updates will be displayed.
  4. Activate the “Require TLS 1.1 or higher for HTTPS connections”

Salesforce TLS 1.0 Critical Update

(Note: Prior to March 4, 2017 you can use these same steps to deactivate.)

Stay focused, be proactive, and test early to handle this pending Salesforce TLS 1.0 disablement.

If you would like help with this transition, please feel free to contact us at www.cirriussolutions.com/contact.