Last week, Salesforce sent out a scary-sounding email announcing that SF is discontinuing support for SSL 3.0 and moving to TLS instead.
Wondering if this is something you need to worry about?
The short answer is: probably not. Don’t worry. Your systems will very likely continue to work just fine after this change. But there are a few caveats, so if you want to learn more, read on.
SSL and TLS
SSL and TLS are both methods of encrypting data. When you’re accessing a “secure” web page, your browser is using one of these protocols. Although TLS has a different acronym than SSL, it’s really just the upgraded version of SSL. An upgrade that’s been around a good while – since 1999! So most modern web browsers and software can use either one. And if they try to connect with SSL and that doesn’t work, they’ll automatically switch to TLS.
So unless you’re still using Netscape for your browser, logging in to SF won’t be any problem. The thing to consider, though, is any integrations you have with Salesforce. Especially older custom integrations.
Salesforce Integrations
Integrations come in two flavors, inbound and outbound.
Inbound integrations are any external app or system that either pulls data out of SF, or puts data in, or both. This includes everything from desktop apps like DemandTools and the Outlook plugin, to online services like Click & Pledge and Form Assembly, to custom-built website integrations like event signups and donation forms.
The good news applies here too. The companies behind commercial products like Click & Pledge will test and make sure their products work with TLS. And for custom integrations, if it’s built with fairly recent languages and tools (including Plone 3 or later), it should support TLS already and work fine.
But if you have a custom-built integration that is older or uses older languages or tools, we’d suggest doing some testing(More on that below).
Outbound integrations are when Salesforce sends commands or data out to an external system. This includes some custom website integrations that sync data from SF to the site, as well as online services like some email platforms, geocoding and legislative district lookups, etc.
The news here is more mixed. Some services have already disabled SSL – they moved faster to address this than SF did. Ideally, this shouldn’t matter. It should work the same as inbound connections – if Salesforce tries to communicate via SSL and it doesn’t work, it should switch to TLS automatically. But there have been some reports that this isn’t always happening. It looks like Salesforce is moving rapidly to correct this (and it may have been limited to the na14 server). But if you have outbound integrations that are critical to your work, it probably makes sense to do some testing.
Testing
Testing is best done in a Salesforce test database (a sandbox). According to the FAQ, as of last Fri (Nov. 7), sandboxes now have SSL disabled. It won’t be disabled in production databases until end of this week (Nov 14) at the earliest. So during that interim, you can try the integration in the sandbox – if it works, you know it supports TLS and it will work in production too.
If you are a Percolator client and have particular concerns about one of your integrations after reading all of this, please get in touch. We can advise on whether testing is called for, and how to go about it.