Starting April 21, 2020, all requests to Elasticsearch Service on Elastic Cloud must use HTTP over TLS (HTTPS) with support for TLS 1.2. We’ve decided to make this change in the best interest of our users so we can ensure the security of data in transit and stay up to date with modern encryption, security protocols, and practices.
This means that TLS 1.0 and 1.1 and unencrypted traffic will no longer be supported for requests to Elasticsearch Service on Elastic Cloud. All client applications that send data to Elasticsearch, Kibana, or APM clusters hosted on Elasticsearch Service will be required to support TLS 1.2. If you use clients that don’t support TLS 1.2 and above, please read the rationale and steps needed for continued operation below.
Why are we removing support for TLS 1.0 and TLS 1.1?
TLS 1.0 and TLS 1.1 are out-of-date protocols that don’t support many newer — and more secure — cryptographic algorithms. Older versions of TLS contain security vulnerabilities that attackers can exploit. A vast majority of encrypted internet traffic already uses TLS 1.2, which was introduced over a decade ago.
The Internet Engineering Task Force is also officially planning to deprecate these protocols. As of March 2020, all major browsers such as Google Chrome, Microsoft Internet Explorer, Apple Safari, and Mozilla Firefox will no longer support TLS 1.0 and 1.1.
Why are we removing support for unencrypted traffic?
Unencrypted traffic (sent over HTTP with no TLS) is insecure and open to attack. We strongly recommend sending any data over HTTP with TLS (HTTPS). This improves the security posture of your deployments while making it harder for attackers to gain access to any sensitive data that might be transmitted.
Who will be impacted?
From our analysis, the vast majority of client requests to our platform are already using TLS 1.2, so this potentially impacts only a very small percentage of clients that are still using TLS 1.0/1.1 or sending unencrypted traffic.
Clients that don’t support TLS 1.2 and force a minimum TLS version of TLS 1.0 or TLS 1.1 will be affected. Those that currently establish unencrypted connections over HTTP will also be impacted. Any client that doesn’t support TLS 1.2 won’t be able to successfully negotiate a connection and will start seeing connection request failures to their Elasticsearch Service deployments.
Will it impact clients that are already up to date and use TLS 1.2?
No, it won’t. The vast majority of requests to our platform are already using TLS 1.2. If you have a client that only supports TLS 1.0 and/or TLS 1.1, we highly recommend you update these clients. Additionally, if you have clients that send data over HTTP with no TLS (encryption) we highly recommend these clients are updated before the deadline.
Elastic clients that send data to the platform, such as Beats, already support TLS 1.2.
What will happen if I don’t update my clients by the deadline?
Any client that doesn’t support TLS 1.2 won’t be able to successfully negotiate a connection and will start seeing connection request failures to their Elasticsearch Service deployments. This means clients that are not updated will be unable to communicate with deployments on Elasticsearch Service.
Which versions of Logstash, Beats, and the Elasticsearch clients started supporting TLS 1.2?
|Product||Min version with support for TLS 1.2|
|Logstash||Logstash has supported TLS 1.2 since Logstash 2.0.0.|
|Beats||All Beats versions support TLS 1.2. For more details on SSL configuration, refer to Beats documentation.|
|Elasticsearch clients||Every 7.x client supports TLS 1.2.|
|Java REST clients||If you're on JDK 8 or higher, TLS 1.2 is supported for both the High Level REST Client and the Low Level REST Client. Since its release, the high-level client has run on JDK 8 and higher, so it has always supported TLS 1.2. Read more: Java REST doc|
|Node.js client||TLS 1.2 support since node.js client v6.x. Read more: Node.js client doc|
|Ruby client||Depends on curl & OpenSSL (v1.0.1) version of the system. OpenSSL v1.0.1 and above support TLS 1.2. Read more: Ruby client doc|
|Go client||TLS 1.2 support since the initial version. Read more: Go client doc|
|.NET client||TLS 1.2 support since v6.3.0 of the client. Read more: .NET client doc|
|PHP client||Depends on curl & OpenSSL (v1.0.1) version of the system. OpenSSL v1.0.1 and above support TLS 1.2. Read more: PHP client doc|
|Perl client||Supports TLS 1.2 since v1.95 of MetaCPAN Read more: Perl client doc.|
|Python client||Python v2.7.x: Some behavior may be platform dependent, since calls are made to the operating system socket APIs. The installed version of OpenSSL may also cause variations in behavior. For example, TLSv1.1 and TLSv1.2 come with OpenSSL version 1.0.1. Read more: Python client doc|
If you have any further questions, please email email@example.com.