Are Remedyforce and Salesforce Affected by the SSL 3.0 POODLE Vulnerability?

Version 2
    Share:|

    Per Salesforce:

    For this vulnerability to be exploited, the following conditions would need to be satisfied:

    1. First, a user must be using a browser with SSL v3.0 support enabled.
    2. From there, an attacker would need to gain control of the connection between your browser and the website you are connecting to.

     

     

    Solution:

    We recommend that if you do not require SSL v3.0, take action to explicitly disable it (and enable TLS 1.0 or greater if not already enabled). Disabling SSL v3.0 eliminates the vulnerability entirely. All modern browsers support this configuration change.

     

    More information on this vulnerability can be found at:

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 (generic)

    https://www.openssl.org/~bodo/ssl-poodle.pdf (detailed)

     


    Updated Salesforce Response 11/6/14:

    Salesforce Disabling SSL 3.0 - Action Items for Partners

    Nov 5, 2014


    Q: Who is affected by this Alert?
    A: Any partner or customer currently using SSL 3.0.


    Q: What is the change?
    A: In November and December 2014 Salesforce will be disabling SSL 3.0 encryption in stages to prevent it from being used to access the Salesforce platform.


    Q: Why is this happening?
    A: At Salesforce, trust is our #1 value, and we take the protection of our customers' data very seriously.  On October 15, Google researchers published details on a security vulnerability (CVE-2014-3566) that affects the Secure Socket Layer (SSL) 3.0 encryption protocol, also known as “POODLE,” which may allow a man-in-the-middle attack to extract data from secure HTTP connections. Although the vulnerability is somewhat difficult to exploit, to further protect customers, we will be disabling SSL 3.0 to fully address this issue.


    Q: How do customers know if they are ready for this change?
    A: After Salesforce disables SSL 3.0 encryption, any channels connecting to Salesforce will need to use TLS 1.0 encryption or higher—see below for supported encryption protocols. There are three different channels that require encryption to access Salesforce: internet browser, API (inbound) integrations, and call-out (outbound) integrations. Here is an overview of each:

    Internet Browsers: By default, all browsers supported by Salesforce have TLS 1.0 enabled. Users should not experience an impact accessing Salesforce in their browser(s) unless they are either using a non-supported browser or they have disabled TLS 1.0 in the browser. To quickly test browser compatibility, one can visit https://developer.salesforce.com (this site has SSL 3.0 disabled). If they are able to visit the site without errors, access to Salesforce via their browser should not be impacted by this change.

    Internet Explorer (IE) 6, which is not officially supported by Salesforce, is capable of handling TLS 1.0 encryption, but it is not enabled by default. If a customer has users on IE 6 and would like assistance on how to enable TLS 1.0, they should log a case via the Help & Training portal.

    API (inbound) Integrations: API Integrations are interfaces or applications that are separate from Salesforce, but use Salesforce data. If a customer has any API Integrations, they need to ensure TLS 1.0 encryption or greater is enabled in the integration. If an API integration was built by or provided by a Salesforce partner, please follow-up with that partner to ensure TLS 1.0 is enabled. 

    Call-out (outbound) Integrations: Call-outs are integrations with Salesforce where Salesforce connects to an outside source to either verify login credentials or pull data. Examples of call-outs include: Delegated Authentication Single-Sign-On (SSO), Outbound Messaging, and Apex call outs. If a customer uses call-out integrations, then they need to ensure TLS 1.0 encryption is enabled in the integration endpoint receiving the call-out.


    Q: What action do customers need to take?
    A: In order for customers to continue to have access to their Salesforce orgs, they need to ensure users’ browsers, API integrations, and call-out integrations support TLS 1.0. If their browser or integration does not have TLS 1.0 or higher enabled after Salesforce makes this change, then users will not be able to access Salesforce.

    Additionally, Salesforce recommends customers disable SSL 3.0 encryption in their own IT environments as soon as possible, unless they use call-out integrations. If a customer uses call-out integrations, and has not already disabled SSL 3.0 in their own environment, then Salesforce recommends that they wait to do so until after Salesforce has disabled SSL 3.0 for outbound requests. 


    Q: When will Salesforce disable SSL 3.0 encryption?
    A: Salesforce plans to disable SSL 3.0 encryption during off-peak hours according to the following schedule:

    For Inbound Encryption Requests (Internet Browsers and API Integrations)

     

    Instances

    SSL 3.0 Disable Schedule

    All Sandbox Instances

    Friday, November 7, 2014

    NA17, NA19, NA20

    Friday, November 14, 2014

    NA2, NA4, NA13, NA15, NA16, EU0, EU2, EU3

    Friday, November 21, 2014

    NA0, NA1, NA3, NA5, NA6, NA7, NA8, NA9, NA10, NA11, NA12, NA14, EU1

    Friday, December 5, 2014*

    AP0, AP1

    Monday, December 15, 2014

    *Please note that we will be disabling SSL 3.0 encryption for NA7, NA8, NA9, NA10, NA11, NA12, NA14 and EU1 on Friday, December 5 rather than Friday, November 28.

    For Outbound Encryption Requests (Call-out Integrations)

     

    Instances

    SSL 3.0 Disable Schedule

    All Sandbox Instances

    Wednesday, December 3, 2014

    All Production Instances

    Wednesday, December 10, 2014


    Q: What additional guidance can you provide on API Integrations?
    A: If you use IBM WebSphere CastIron Client, apply the following patch from IBM. If you use a Java-based client, we do not anticipate that you will experience issues as a result of this change. If you use Informatica, we recommend you contact Informatica for more information on how to prepare for this upcoming change. 


    Q: Which non-SSL 3.0 encryption protocols does Salesforce support?

    A: Salesforce currently supports the following encryption protocols:

    • For inbound requests: TLS 1.0, and TLS 1.2
    • For outbound requests: TLS 1.0


    Q: What should I do if I am experiencing handshake errors? 
    A: We recommend you test the call-out integration in a Sandbox. If you continue to receive handshake errors in the Sandbox, then log a case.


    Q: I have AppExchange packages installed in my Salesforce org, what should I do?
    A: If you use AppExchange packages and would like to ensure you are prepared for this change, connect with your AppExchange vendor to ensure they support TLS 1.0.


    Q: What specific action steps should partners take? 
    A: We currently advise partners to take the following actions immediately:

    1. 1. In advance of Salesforce disabling SSL 3.0, ensure that all integrations are sending TLS 1.0 or 1.2 and that this is working properly.
    2. 2. If your customers have questions about this change, refer them to the Knowledge Article on the Success Community for more details.  Encourage them to log a case in their instance if they experience a problem.

    https://help.salesforce.com/apex/HTViewSolution?urlname=Salesforce-disabling-SSL-3-0-encryption&language=en_US

    1. 3. Partners should log a case detailing any concerns or issues. Be specific about the error(s) you may be receiving, the impact of those errors on your app or your business, and if it is affecting all of your customers, or a subset of customers.  We are reviewing all partner cases to determine best practices and recommendations.


    Where can I get more information?

    Refer to the published Knowledge Article for more details.  You can also search on #poodle in the Partner Community for relevant discussions. Continue to follow the Official: Partner Community Chatter Group for updates.  With any other questions or concerns, please log a case in the Partner Community.

    #Alert141105