# Removing Support for Outdated Encryption Mechanisms [Blog](/blog/)>[Technology](/blog/category/technical/)>Removing Support for Outdated Encryption Mechanisms Removing Support for Outdated Encryption Mechanisms =================================================== September 19, 2019 | By [ Alwyn Davis](https://www.instaclustr.com/blog/author/alwyn/) [ ](https://x.com/intent/tweet?text=Removing%20Support%20for%20Outdated%20Encryption%20Mechanisms&url=https://www.instaclustr.com/blog/removing-support-for-outdated-encryption-mechanisms/) [ ](https://www.linkedin.com/shareArticle?mini=true&url=https://www.instaclustr.com/blog/removing-support-for-outdated-encryption-mechanisms/&title=&summary=Removing%20Support%20for%20Outdated%20Encryption%20Mechanisms&source=) At Instaclustr, security is the foundation of everything we do. We are continually working towards compliance with additional security standards as well as conducting regular risk reviews of our environments. This blog post outlines some technical changes we are making that both increases the security of our managed environment and enables compliance with a wider range of security standards. From October 9, 2019 AEST newly provisioned Instaclustr clusters running recent versions of Cassandra and Kafka will have support for the SSLv3, TLSv1.0 and TLSv1.1 encryption protocols disabled and thus require the use of TLS 1.2 and above. From this date, we will also begin working with customers to roll this change out to existing clusters. Instaclustr-managed clusters that will be affected are: - Apache Cassandra 3.11+ - Apache Kafka 2.1+ Why are we doing this? ---------------------- The protocols we are disabling are out of date, have known vulnerabilities and are not compliant with a range of public and enterprise security standards. All identified clients that support this version of Cassandra and Kafka support TLS1.2. How can I test if I will be affected? ------------------------------------- ### Cassandra The *cqlsh* CLI will need to be changed to request TLSv1.2 ([otherwise it defaults to TLSv1.0](https://github.com/apache/cassandra/blob/cassandra-3.11/pylib/cqlshlib/sslhandling.py#L63)). Assuming a [cqlshrc file based on the Instaclustr example](https://www.instaclustr.com/support/documentation/cassandra/using-cassandra/connect-to-cassandra-with-cqlsh/), the updated entry should be: \[ssl\] certfile = full\_path\_to\_cluster-ca-certificate.pem validate = true factory = cqlshlib.ssl.ssl\_transport\_factory version = TLSv1\_2 1 2 3 4 5 6 7 8 9 \[ssl\] certfile = full\_path\_to\_cluster-ca-certificate.pem validate = true factory = cqlshlib.ssl.ssl\_transport\_factory version = TLSv1\_2 **Note:** If running CQLSH from on Mac OS X, the system Python is not updated and will not support the TLSv1\_2 option. You should instead manually update your system Python or run cqlsh from a Docker container. Clients built on the [Datastax Apache Cassandra Java driver](https://docs.datastax.com/en/developer/java-driver/4.2/manual/core/ssl/#jsse-programmatic) can create a custom SSLContext that requires that TLSv1.2 is used e.g. ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); 1 ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); If the client is able to successfully connect, then it confirms that your Java environment supports TLSv1.2 (i.e. is recent enough and is not configured to disable it). ### Kafka If using the official Apache Kafka Java client (or the Instaclustr ic-kafka-topics tool), the client configuration can be updated to allow only TLSv1.2. For example, [based on the Instaclustr example configuration](https://www.instaclustr.com/support/documentation/kafka/using-kafka/use-kafka-with-java/), the enabled protocols becomes: ssl.enabled.protocols=TLSv1.2 1 ssl.enabled.protocols=TLSv1.2 If the client is able to successfully connect, then it confirms that your Java environment supports TLSv1.2 (i.e. is recent enough and is not configured to disable it). Summary ------- We understand that testing and changing systems is a time-consuming process. Given the widespread support for TLSv1.2 we do not anticipate that this change will actually impact any current systems. If you have any questions or concerns, please do not hesitate to contact us at . ![mail icon]()#### Get the latest articles for open sourceIn your inbox Sign up now ### Related content [ Zero Downtime Migration to Instaclustr Yes, we can migrate existing Cassandra clusters to Instaclustr without any downtime. Here's what to expect from the process... ](https://www.instaclustr.com/blog/zero-downtime-migration-to-instaclustr/) [ Workflow Comparison: Uber Cadence vs Netflix Conductor When choosing what’s right for your company’s opensource workflow needs it is important to know the difference and similarities ... ](https://www.instaclustr.com/blog/workflow-comparison-uber-cadence-vs-netflix-conductor/) [ Will Your Cassandra Database Project Succeed?: The New Stack Open source Apache Cassandra® continues to stand out as an enterprise-proven solution for organizations seeking high availability... ](https://www.instaclustr.com/blog/will-your-cassandra-database-project-succeed-the-new-stack/) ×Sign upto ourNewsletter -----------------------