I have an existing integration with Twilio that works great - Twilio posts a message to a custom SFDC REST endpoint, and we can generate a new SMS message by calling out to the standard Twilio REST API.

Yesterday, I received an email referencing this security alert, which states that Twilio will be removing support for SSLv3, and requiring any platform interacting with Twilio to use TLS:

For customers only supporting SSLv3 for inbound HTTP requests from Twilio, we plan on discontinuing this service on 22 October 2014 at 9am PDT / 1600 UTC. Customers with applications that only support SSLv3 are encouraged to upgrade to TLS as soon as possible, as SSLv3 will be unavailable on that date.

Does anyone know if this will break my current integration? To my knowledge, I have never set an option regarding the method of Secure Transport anywhere for inbound or outbound posts - I just set the endpoint, and it worked fine. Is there so way to test it in a Sandbox/Dev system? I am struggling to find anything in documentation to even know if this will be an issue.

4 Answers 4


It will likely break your integration. One of the services I call into for the project I am currently working on uses AWS, and they too turned off SSLv3. Now, when I call into the service, I get a handshake_failure error.

Salesforce is working on a solution, but has not yet come up with one by the sounds of it, according to this post on the Developer Boards: https://developer.salesforce.com/forums/?id=906F0000000AmTZIA0

As far as a setting that gets around SSL via another transport option, I'm still looking into whether this can be accomplished myself.

  • Ah - very helpful. I also talked with Dev Support yesterday, and they think that because inbound supports TLS 1.2, inbound messages from Twilio should work, but I think you are right - my outbound message will likely fail. Not quite sure how to work around that if I'm honest... Oct 22, 2014 at 15:42
  • 3
    Here's the response I got back from an SFDC case I just opened: I am <Rep> from Salesforce Developer Support Team. I have taken ownership of your case regarding POODLE vulnerability. At present some outbound calls are initiated using SSLv3 ClientHello, so if this is disabled on your server, there'll be a handshake failure. Until then, it is advised that you support this for incoming calls (received from Salesforce). At present R&D and our Tech Ops organization are aggressively working on a strategy around this. Once this is finalized, there will be a tech comm broadcast as expected. Oct 22, 2014 at 19:12
  • Can confirm doing Apex callouts to a service that has disabled SSLv3 will fail. Salesforce better fix this quick or they are going to have a major issue with tons of code breaking as lots of service are ending support in the next week or two.
    – TehNrd
    Oct 29, 2014 at 22:38
  • 3
    FYI... Good news. Here is the response I got from my case: The R&D team shall be releasing this on 11/4/2014. After that you may turn off SSLv3 without running into the handshake failures. Oct 30, 2014 at 20:35
  • @JamesLoghry That is indeed good news. If possible, is there anything that can be referenced on that fix? Maybe a known issue? Nov 4, 2014 at 1:04

There's an updated Knowledge Article on this issue, please review: https://help.salesforce.com/apex/HTViewSolution?urlname=Salesforce-disabling-SSL-3-0-encryption&language=en_US

Edited 11.6.14 - Please review the response from our support team at: https://developer.salesforce.com/forums/ForumsMain?id=906F0000000AmTZ

  • Hi April, can you confirm that there is a fix for outbound calls to services not supporting SSL 3.0 due on the 4th of November? Or do we need to wait until the 10th of December before Saleforce discontinues support for SSL 3.0? Nov 4, 2014 at 1:07
  • 1
    Hey Daniel, we had our support team respond to the thread here: developer.salesforce.com/forums/ForumsMain?id=906F0000000AmTZ. Please check that out as it should cover your questions. Nov 6, 2014 at 18:36

In the interim, you can utilize a proxy to translate between sslv3 and tls1.2

Look @ cors-anywhere on github for a heroku deployable proxy.

  • Heroku has disabled SSLv3, so while this is still a viable, if ugly work around, you'll need to host your proxy somewhere that's still accepting incoming sslv3.
    – Kevin P
    Nov 4, 2014 at 16:18

We have a similar issue and opened a case for SFDC support. The support pointed us to https://help.salesforce.com/apex/HTViewSolution?urlname=Salesforce-disabling-SSL-3-0-encryption&language=en_US

According to this article above, the ssl client for outbound calls will be disabled in December. I don't know why James Loghry said it would be disabled on 11/4. Maybe it's a different issue.

  • 11/4 was the release of the support for TLS handshake I believe not the disabling of SSL3
    – Eric
    Nov 3, 2014 at 19:23
  • Latest from SFDC: "So fix is being rolled out in phases so its possible your node has got the fix. Finally all of them should be completed by wednesday evening. So yes if your problem is fixed then it should not reoccur and use TLS only. " I tested one of my outbound api on a testing account and it already works as expected.
    – Yangzi Liu
    Nov 5, 2014 at 2:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .