Support ending for TLS 1.0/1.1 and unencrypted HTTP traffic to Elasticsearch Service on Elastic Cloud

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?

Questions?

If you have any further questions, please email [email protected].