In the first versions, one of the things that was missing most was encryption in the communications between the various elements of the architecture.

This caused the need, in order to guarantee the security of our installations, to be solved by means of VPNs, SSH tunnels and other common solutions to protect non-secure services. This meant an overload of the systems and complicated their administration and maintenance.

Fortunately, the people at Zabbix have solved it and there is now support, since version 3.0, for encrypting communications based on TLS v.1.2.

As a first technical point, and we think it is an excellent idea, is the support they have given to 3 different libraries: OpenSSL, GnuTLS and mbedTLS. This, besides giving a great flexibility when using some specific feature that may interest us from any of these libraries, may be vital in case a vulnerability is discovered in one of them (the infamous Heartbleed for example), allowing to change to another more secure one in a more or less simple way.

Having said that, let's see what 2 encryption methods are proposed:

• Pre-Shared Key: this is the easiest method to configure, but probably the most difficult to manage on a large scale.
  
  Essentially it involves generating a key - between 32 and 512 characters - that has both - and ideally only both - ends of the communication complex enough to be difficult to guess. It is configured in the field we see in the image called "PSK". The field "PSK identity" is a basic identifier that is not secret and is not encrypted; we could put "muutech", for example, or a domain.
  
  
• Based on certificates: it is the most complex method to configure (if you are not used to work with certificates) but it is also the option that best scales and can be better managed because there are several methods and software for secure management of certificates.
  
  As almost always when working with certificates, it is necessary a certification authority (CA or Certificate Authority) to sign the certificates we generate. Zabbix does not accept "self-signed" certificates. This certification authority can be ourselves (it is a matter of trust) or use an external agent (such as FNMT, GlobalSign, etc.). On the Internet you can find 1001 tutorials that will explain how these certificates can be generated and signed. The idea is to generate and sign a certificate for the server, for each agent, proxy, etc whose communication we want to encrypt. These certificates are put in the right directory for each element, we configure in the host/proxy what we need as you can see in the image... et voilà!

One of the things that we like very much is that it is not mandatory to activate the encryption for all the communications, but that it is possible to do host to host, in a gradual way and compatible with agents that we have installed from previous versions, allowing to select individually the chosen method according to the communication direction: for the outgoing connections we can choose only one, but for the incoming ones we can put several options, giving that compatibility that we are looking for.

In our host view, we can see the type of encryption in each direction. The first box is the outgoing traffic encryption ("NONE" in the example), which would represent the connection from the server to the agent for example, and in the 3 boxes on the right the possible methods for the incoming traffic from the agent to the server:

Let's hope you found it useful! Any doubt or question, here we are :)