Changes in TLS Cipher Suite Requirements¶

As part of Snowflake’s continued commitment to providing best-in-class Transport Layer Security (TLS) we are migrating all endpoints used by connectors, drivers, or SQL API clients to a new load balancing stack based on the open source Envoy Proxy, as described in Snowflake’s migration to Envoy for traffic management.

While this migration is expected be transparent for most customers, there are two changes which may require action, depending on client-specific configuration:

1. Change of TLS server-side implementation.

2. Enabling of TLS 1.3 and deprecation of weak TLS 1.2 cipher suites.

Details follow:

1. When a region is switched over to terminating TLS using Envoy, some Snowflake Java-based clients with custom Security Provider configurations may experience issues establishing TLS connections. Configuration of this kind is very uncommon. To reduce connectivity problems, Java clients should verify that a security provider that supports Elliptic Curve Cryptography (ECC), such as SunEC or BouncyCastleProvider, is enabled in their java.security file. SunEC is enabled by default.

   For more details on how to ensure your clients are configured for compatibility see Snowflake knowledge base article Envoy migration updates.

2. Once a region is migrated to Envoy, TLS 1.3 is automatically available, and capable clients will begin negotiating connections using this most up-to-date version of TLS. TLS 1.2 will continue to be supported.

   Initially, to maintain backwards compatibility for as many customers as possible, the following TLS 1.2 cipher suites will continue to be supported in multi-tenant regions:

   Strong ciphersuites (preferred, and always used if supported by the client):

   • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

   • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

   • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

   Weak ciphersuites (for backwards-compatibility, not available in US Gov regions)

   • TLS_RSA_WITH_AES_128_GCM_SHA256

   • TLS_RSA_WITH_AES_256_GCM_SHA384

   • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

   • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

   • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

   • TLS_RSA_WITH_AES_256_CBC_SHA

   • TLS_RSA_WITH_AES_128_CBC_SHA

   • TLS_RSA_WITH_AES_128_CBC_SHA256

   • TLS_RSA_WITH_AES_256_CBC_SHA256

   Approximately one month after TLS 1.3 is enabled:

   1. For accounts observed to be connecting exclusively via TLS 1.3 or the preferred TLS 1.2 cipher suites above during this period, and for all newly created accounts, TLS 1.3 or TLS 1.2 with strong ciphersuites will be made mandatory when connecting to Snowflake using public IP addresses. Weak TLS 1.2 cipher suites will no longer be an option.

   2. For accounts identified to be connecting with TLS 1.2 cipher suites on the weak list above, targeted communications will be sent recommending a client-side upgrade to move to TLS 1.3 or strong TLS 1.2 ciphers. These accounts will continue to be able to use legacy cipher suites for up to 3 months following the targeted notification.

   3. After the 3 month notification period, a choice of strong TLS 1.2 cipher suites or TLS 1.3 will be mandatory for both Public IP and Private Link / Private Service Connect access.

No action is required at this time, but this information is being provided now so that clients may proactively upgrade their TLS client implementations ahead of the targeted communication requiring an upgrade.

TLS 1.3 offers multiple improvements, including faster TLS handshakes and simpler, more secure cipher suites. These changes provide better performance and stronger security. Upgrading to a TLS 1.3 compatible client is highly recommended.

When will these changes be occurring?

The change in TLS server implementation will be rolled out on the following schedule:

Changes to remove default support for weak ciphersuites will follow at least 1 month after each region receives this change-of-implementation rollout.

Ref: 1727