You might have heard that Salesforce is disabling TLS 1.0 encryption protocol. Unless you are a network admin or very passionate about IT, this will sound like Chinese for you. In this blog I’ll explain some key points about TLS. To make things easy to understand for non IT techies, I will use the secret Ice cream recipe analogy.
Now let’s shed some light on what roughly 3.5 BILLION people use of when they go ONLINE. Yep, TLS concerns not only Salesforce, it impacts every connection on the internet at some point. Let’s get started.
What is TLS?
We all know that the Internet is one big network setup with its own protocol suite, most commonly known as TCP/IP.
These protocols enable us to communicate across the Internet almost instantly. As the internet has evolved, so has the need to protect our privacy. This is where TLS becomes important to understand.
TLS is the protocol to secure your online communication from prying eyes by encrypting it.
At first there was the SNP (secure network protocol API 1993), then came the SSL (Secure Socket Layer 1995) that evolved to TLS 1.0 in 1999. So you might see a glimpse of why the need to replace the “prehistoric” TLS 1.0. As Internet grew, people developed new ways of bypassing the security protocols. With our use of the internet growing ever larger, so has our need for security.
Now to explain the details a bit:
Introducing: Ben and Jerry (I like icecream ;)). Ben lives in Belgium and Jerry in the U.S. Ben would like to send a letter to Jerry containing his secret Ice Cream recipe (like I promised you in the intro). Ben has the idea that someone might intercept the letter and read its contents, and even worse: replace it with another recipe. So Ben is now faced with 2 challenges:
- Securing the contents of the letter, and
- Guaranteeing the letter’s integrity.
After a lot of thinking, Ben reads this blogpost and decides to apply the TLS protocol for sending his letter:
- Ben (the client) initiates “the handshake” by sending Jerry (the server) a “ClientHello message” where he specifies:
- The highest TLS protocol version it supports
- A random number
- A list of suggested CipherSuites and suggested compression methods, if he’s attempting to remove a handshake he might include a session ID.
- Jerry (the server) responds with a “ServerHello message”, containing:
- The chosen protocol version
- A random number
- CipherSuite and compression method from the choices suggested by Ben (the client). To confirm or allow a resumed handshake Jerry may send a session ID.
But wait, there’s a trick! The chosen TLS protocol version should be the highest that both Ben and Jerry’s support. And because Ben is a smart man he no longer supports TLS 1.0 because he has read that:
- 1999 TLS1.0 was developed
- It was heavily based on SSL and designed to be a single non-proprietary security solution.
- To ensure compatibility with older systems that still use the first version, a downgrade mechanism was implemented, allowing users to negotiate a weaker SSL protocol if one of the parties (server or client) involved could not use a more recent version.
- This turned out to be a major flaw that would facilitate a POODLE attack to take place by forcing servers to use obsolete SSL.
- 2006 TLS 1.1 was released after a series of improvements.
- 2008 TLS 1.2 was released based on TLS1.1 specs but with some major differences concerning the encryption cipher algorithms.
- The PCI Council says you must remove completely support for SSL 3.0 and TLS 1.0.
In short: clients (like Ben) and servers (like Jerry) should disable SSL 3.0 and TLS 1.0 and then preferably transition everything to the current TLS 1.2. However, TLS 1.1 can be acceptable if configured properly.
How does all this fit into Salesforce?
Ask yourself; how do you access Salesforce? You usually open a browser or a third party application (through API inbound integration or Call-out outbound integration). Either of those need a secure connection to the Salesforce platform, and that is achieved through TLS. Salesforce recently announced that it will no longer support TLS 1.0. This means that if you use somewhere TL 1.0 in your browser or in a third client or application that integrates with Salesforce in order to reach the Salesforce platform you might soon (early 2017) find yourself unable to log into Salesforce or integrate with the platform.
Since we are still in a transition period, TLS 1.0 is still supported for Salesforce existing production orgs and you can still re-enable* it in production org created recently (after summer 16), but TLS 1.0 is not supported anymore for sandbox orgs. *You can re-enable it by going to “Setup”, under “Build” click on “Critical Updates”, look for “Require TLS 1.1 or higher for HTTPS connections.
Even if it may not have impacted you; if you do not take the necessary steps to adapt to current security best practices, sooner or later you will find yourself stranded on an island in this vast ocean of information.
So, to sum it up:
- Have a look that your browser is compatible with the latest security trends. You can do that by searching for “check my browser for TLS”.
- If the application you use to integrate with Salesforce has not been updated in a while, check with your provider if the software is TLS 1.1 enabled or if it uses .NET 3.5, Python 2.7.8, Java 6 or Windows Server 2008.
If you have difficulties understanding why you need to adapt, think of it like this:
If you own a car, a good practice would be to do regular maintenance service on it. After all it is the best thing both for your security and for your pocket. You wouldn’t want to have to repair your car because of an accident, or replace an expensive part because of poor or no maintenance.
If you are still not sure, and want to have a check on the usage of TLS in your salesforce Environment, do not hesitate to contact us or visit our Salesforce page. Because if is your car, then PwC can be your trusted garage and maintenance adviser.
