Why does Search Guard require SSL/TLS?

by Claudia Kressin on July 9, 2016

We get a lot of questions like “Why does Search Guard require TLS?” or “Can I run Search Guard without SSL?”.

We officially open the Search Guard blog by explaining the whys behind the decision to make SSL/TLS mandatory. We will post articles regarding Search Guard on a regular basis, so check back often. If you want us to write about a specific topic, just drop us an email or use the comment section below.

tl;dr: In order to secure your data against attacks from the outside and the inside, all traffic must be secured via TLS. Without it, you leave your cluster open for attacks.

First, let me start with admitting that we have a very strong opinion on this topic. Our principle is: If we offer a security plugin, we need to make sure that it does exactly what we claim it does. And that is protecting your data against malicious attacks by all means. We decided to make SSL/TLS mandatory, because without it, you would leave your cluster open for a wide range of attacks.

We understand that if you have no prior knowledge about TLS, getting the concepts behind it can be confusing. You need to deal with certificates, certificate authorities, key- and truststores and so on. But on the other hand, data security will always be a topic that comes at a price. We believe that you should familiarize yourself with security technologies such as TLS, so you know exactly what is happening in the background to secure your data.

So, let’s jump right in and talk about some of the comments we received (as always, thanks very much for your feedback folks!):

“I just want to test Search Guard quickly and don’t want to be bothered with TLS.”

If you just want to test drive Search Guard, or set up a PoC, you do not have to deal with the TLS layer of Search Guard.

update: The Search Guard Bundle has been replaced by our Search Guard Demo Installer see the documentation to learn more.

We provide an Elasticsearch installation pre-configured with Search Guard and Search Guard SSL, un-creatively called “Search Guard Bundle”. You just need to download, unzip and start. The bundle comes with the enterprise features as well, so you can test all of them. The sgadmin CLI (to update the configuration) is also pre-configured with the correct command line settings. The only thing you need to do is update the configuration files, and run sgadmin.sh.

If you want to dig a little bit deeper into TLS, you can also use our example PKI scripts that ship with Search Guard SSL. The scripts generate all required certificates for a 3-node cluster.

Last but not least: We’re also planning to ship Search Guard with demo certificates in future.

“I do not need inter-node encryption.”

If the traffic between the nodes is not encrypted, anyone with access to your network can easily spy on your data. And, furthermore, also modify it. So, without SSL you leave yourself vulnerable for those kinds of attacks. However, there is another very important reason to use TLS, and that is that TLS is much more than just encryption:

When talking about SSL/TLS, most people immediately think about HTTPS and that it is used for encrypting sensitive data, such as username and password on a login page. If the data is encrypted, no one can see it in clear text, and everything is fine.

Right? No, unfortunately not. Encrypting data alone is not enough to secure the communication between two systems. You also need to make sure that the system you are talking to is indeed the correct one, and not a malicious attacker impersonating it. In other words, the other system has to prove its identity to you before you send any data, and that is exactly what TLS provides.

Can I see your ID please?

During the first steps of the SSL handshake protocol, the server sends its certificate to the client. The client verifies the certificate, and thus the identity of the server. If this verification fails, the handshake is aborted. If it succeeds you can be pretty sure that the server you are talking to is indeed the one it claims to be.

While it is common that only the server has to prove its identity to the client, TLS is not limited to that. The server can also request a certificate from the client and check the clients identity. This is called “Client Authentication”, and is supported (but not mandatory) by Search Guard.

To sum it up, TLS you can make sure that:

  • The data cannot be sniffed
  • The data can not be modified
  • Only trusted clients or nodes can interact with the cluster

In fact, if you do not need advanced authentication/authorization, and just need to make sure that only trusted parties can query,  update or delete data, TLS is all you need. Some users therefore only install the Search Guard SSL plugin, because they do not need all the other features.

“My cluster runs in a private, secure network, I do not need SSL.”

When we talk about hackers attacking networks to steal data, most of us have this picture in mind: Someone on the other side of the globe sits in a dark room, only lit by three monitors that this person is watching simultaneously, while typing on the keyboard with lightning speed.

55% of all attacks come from the inside

But the truth is, less than half of all attacks come from outside your network. The other attacks actually occur from the inside. It could be one of your employees, contract workers or even vendors or business partners. An IBM study shows that 60% of all attacks come from “anyone who has physical or remote access to a company’s assets”:

IBM Security Study

More resources about inside threats:


“My cluster runs behind nginx which does SSL already.”

Yes, but this only makes sure that the traffic to and from your webserver is secure. Everything behind it is unprotected and thus insecure. Again, any attacker that has access to your network would be able to steal your data.

Getting security right

Getting security right can be complex and requires an effort. We believe it’s better to familiarise yourself with the concepts behind SSL/TLS than to leave you with a half-baked solution that leads you to believe your data is secure.

Note: We realize TLS is not the silver bullet for security, and has some flaws of its own. However, at the time of writing, we think that TLS is best suited for the purpose of Search Guard.

Image source: Tashatuvango/Shutterstock

Claudia KressinWhy does Search Guard require SSL/TLS?


Join the conversation
  • A WordPress Commenter - November 18, 2017 reply

    Hi, this is a comment.
    To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.
    Commenter avatars come from Gravatar.

  • Matthew Dolman - May 30, 2018 reply

    This is really frustrating when trying to run inside a containered environment in which nodes do not communicate across http. Our external certificates are all handled by a proxy with an automated renewal system and so forcing this effectively rules us out.

    Jochen Kressin - June 25, 2018 reply

    If you are talking about TLS on the REST layer (HTTPS), well, this can be switched off by setting:

    searchguard.ssl.http.enabled: false

    The article is mainly about TLS on transport layer, which is indeed mandatory due to security considerations.

  • Novice - February 21, 2019 reply

    If SSL is so critical to SG, how come it can be switched off on the REST layer?

    floragunn - April 5, 2019 reply

    Because there is one particular use case that some customers need when operating high traffic ES clusters, namely data ingestion. These customers ingest a lot of (bulk) data and cannot tolerate even a 3%-5% performance decline when using SSL. TLS on REST layer can be switched off on a per-node basis, it’s not a black/white decision. So sometimes customers disable SSL on their data ingestion node(s) while having it enabled on all others. True, this is not an ideal scenario from a security point of view. Things are bit different on the transport (inter-node) layer. Switching TLS off there means we cannot identify trusted nodes in the cluster anymore. Since inter-node traffic is allowed to do anything, an attacker could spin up a malicious node, let it join the cluster and would have full control over everything immediately. That’s why TLS on transport is mandatory with Search Guard, while you can disable SSL on REST layer for single nodes.

Join the conversation