What is happening?

Starting in the first quarter of calendar year 2016, we will begin disabling the TLSv1.0 and v1.1 encryption protocols. This phased approach will prevent it from being used to access Qvalent/Westpac services within inbound and outbound connections.

Why is this happening?

At Qvalent, trust is our #1 value, and we take the protection of our customers' data very seriously. To maintain the highest security standards and promote the safety of your data, we occasionally need to make security improvements and retire older encryption protocols. To maintain alignment with these best practices and updated compliance requirements from the PCI Security Standards Council, Quickstreamwill disable the use of TLS 1.0 for connections to and from Quickstream.

How do I know if we are ready for this change? 

After Quickstream disables TLS 1.0, any inbound connections to or outbound connections from Quickstream will need to use the TLS 1.1 or TLS 1.2 encryption protocol. This change also impacts access to web sites, such as Quickstream Communities, Customer and Partner portals, Force.com sites, and Site.com.

Three different channels require encryption to access Quickstream: internet browser, API (inbound) integrations and call-out (outbound) integrations. An overview of each follows:

Internet Browsers

 You and your users should not experience an impact accessing Quickstream in your browser(s) unless you are using a non-supported browser or you have disabled the supported encryption protocols in the browser. To quickly test your browser compatibility, you can visit our test site, which has TLS 1.0 disabled. If you are able to view the site without errors, access to Quickstream via your browser should not be impacted by this change. If you experience errors, please refer to the compatibility guidelines below:

See TLSv1.2 Browser Compatibility

Internet Explorer Support for TLSv1.2

API (inbound) Integrations

 API Integrations are interfaces or applications that are separate from Quickstream, but use Quickstream data. If you have any API Integrations, please ensure that the TLS 1.1 and/or TLS 1.2 encryption protocols are enabled in those integrations.

API integrations that use Java will generally need to use Java 8 or higher to enable TLS 1.1 and TLS 1.2 in call-outs by default. Another option is to use Java 7 and enable TLS 1.1 and/or TLS 1.2 using the https.protocols Java system property, if applicable, and/or source code changes to enable TLS 1.1 and TLS 1.2 on SSLSocket and SSLEngine instances.

Services that run on Windows Server systems and use Microsoft Secure Channel for TLS will need to run on Windows Server 2008 R2 or higher. This generally includes most .NET applications and Microsoft Internet Information Server (IIS). Earlier versions of Windows Server do not support TLS 1.1 or TLS 1.2.

API Integrations that use OpenSSL will need to use OpenSSL 1.0.1 or newer. Earlier versions of OpenSSL do not support TLS 1.2 or TLS 1.1.

API Integrations using NSS will need to use 3.14 or newer (preferably 3.15.1 or newer). Versions prior to 3.14 do not support TLS 1.1, and versions prior to 3.15.1 do not support TLS 1.2.

To test the compatibility of an API client that uses SOAP to communicate with Quickstream:

1. Set up an API client in a test environment.

2. In that test environment, change the API client's login endpoint hostname from login.Quickstream.com or [MyDomain].my.Quickstream.com to tls1test.Quickstream.com.

   1. As an example, change https://login.Quickstream.com/services/Soap/u/32.0 to https://tls1test.Quickstream.com/services/Soap/u/32.0 while leaving the path as-is.

3. Log in with that API client.

4. If you see an error message that resembles the following: "INVALID_LOGIN: Invalid username, password, security token; or user locked out." or “Content is not allowed in prolog.”, then this test passed and your integration works with either TLS 1.1 or TLS 1.2.

   1. The presence of this response means that the underlying TLS connection was successful, despite the higher-level error. The TLS connection is the focus of this test.

5. If you instead see an error message that involves TLS or HTTPS, then the test has failed. Your API client will require adjustments or upgrades to operate properly with Quickstream, when Quickstream deactivates TLS 1.0.

To test the compatibility of an API client that uses REST to communicate with Quickstream:

1. Set up an API client in a test environment.

2. In that test environment, change the API client's access token retrieval endpoint hostname from login.Quickstream.com or [MyDomain].my.Quickstream.com to tls1test.Quickstream.com.

   1. As an example, change https://na1.Quickstream.com/services/oauth2/token to https://tls1test.Quickstream.com/services/oauth2/token while leaving the path as-is.

3. Alternatively, it's possible to change an API client's service URL from [instance].Quickstream.com or [MyDomain].my.Quickstream.com to tls1test.Quickstream.com.

   1. As an example, change https://na1.Quickstream.com/services/data/v32.0/ to https://tls1test.Quickstream.com/services/data/v32.0 while leaving the path as-is.

4. If you see an OAuth error, an "INVALID_SESSION_ID Authorization required" error, or a "400 Bad Request" error, then this test passed.

   1. The presence of this response means that the underlying TLS connection was successful, despite the higher-level error. The TLS connection is the focus of this test.

1. If you instead see an error message that involves TLS or https, then the test has failed. Your API client will require adjustments or upgrades to operate properly with Quickstream, when Quickstream deactivates TLS 1.0.

Call-out (outbound) Integrations

 Call-outs are integrations where Quickstream refers to an outside source to either verify login credentials, push data, or pull data. Examples of call-outs include: Delegated Authentication Single-Sign-On (SSO), Outbound Messaging, and Apex call-outs. If you use call-out integrations, please ensure that TLS 1.1 and/or TLS 1.2 are enabled in those integrations.

What action do I need to take?  

In order to maintain access to your Quickstream orgs, you need to ensure your browsers and integrations that use inbound connections to or outbound connections from Quickstream have TLS 1.1 and/or TLS 1.2 enabled. If your browser or integration does not have TLS 1.1 or higher enabled after we make this change, then your users will NOT be able to access Quickstream. We recommend that you begin planning to support TLS 1.1 and TLS 1.2 as soon as possible. NOTE: API-based software that Quickstream makes available for download, such as the Apex Data Loader, plans to achieve compatibility with TLS 1.1 and TLS 1.2 by the end of the Spring '16 release.*

* Timeframe subject to change

We only have a small number of Quickstream users, all of whom use regular browsers to access Quickstream. What action do we need to take?

In order to maintain seamless access to your Quickstream orgs, you need to ensure that browsers connecting to Quickstream have TLS 1.1 encryption or higher enabled. To quickly test your end user’s browser compatibility, have them visit our test site. The test site has TLS 1.0 disabled. If your end users pass the test, no action to update their browsers is necessary.

When will Quickstream disable TLS 1.0 encryption?

Quickstream plans to disable TLS 1.0 encryption according to the following schedule:

Where can I get more information?

If you have any additional questions, please reach out to Customer Support by opening a case via the Help & Training portal.