How is Datafari secured in HTTPS

Starting from Datafari 6, we decided to have end to end encryption for all the communications into Datafari.

The main difference with the previous version of Datafari (version 5) is that we have an Apache server into Solr servers too. So now all the servers into Datafari cluster contain an Apache server. Of course, if you use Datafari CE or Datafari EE into monoserver mode, there will be no difference from before.

So now, even the communication between Solr servers is encrypted. So for example if the main Solr collection is sharded, one shard will query the other shards with TLS.

All the communications between the servers will transit via their respective Apache server in order to keep a TLS communication at all times.

See the architecture page for more information : /wiki/spaces/DATAFARI/pages/559415376

There are many ways to secure an application.

We can either secure each component of Datafari : Solr, Tomcat but it needs more work to manage the security at the level of every component : management of the certificates, configuration specific for each application.

Another way of securing the application is to use SSL Offloading. It is the security that we chose into Datafari. Basically we delegate the functions required for SSL/TLS, namely the handshake and the encryption/decryption to a dedicated component in front of the user. So all the servers behind the reverse proxy communicate as usual.

More precisely it is called SSL Termination in this case :

The proxy server/load balancer we use for the SSL offloading acts as the SSL terminator. When a client attempts to connect to Datafari, the client still has a secure connection with the SSL terminator, which is acting as a pass-through.
The Datafari architecture is like this for monoserver and multiservers :

Architecture Apache reverse proxy monoserver

Architecture Apache reverse proxy multiserver

This solution is a good compromise between the secuirty and the maintenance. The network part between the load balancer and the Datafari servers can be more secured by isolating the servers by their own VLAN or IPSEC tunneling for example.

By using VLAN, we avoid all broadcast attacks like ARP cache poisoning, DHCP spoofing, smurf attack,, MAC table overflow, etc …)

According to section 4.1 of the PCI Data Security Standard any merchant handling credit card data should:

"...use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”

This means that Front End SSL is allowed, as once the data reaches the load balancer, it is considered to have entered a secure private network.

 For Datafari 4.3 EE

For Datafari 4.3 EE

The documentation below is valid from Datafari v4.3 only EE version

There are many ways to secure an application.

We can either secure each component of Datafari : Solr, Tomcat but it needs more work to manage the security at the level of every component : management of the certificates, configuration specific for each application.

Another way of securing the application is to use SSL Offloading. Basically we delegate the functions required for SSL/TLS, namely the handshake and the encryption/decryption to a dedicated component in front of the user. So all the servers behind the reverse proxy communicate as usual.

More precisely it is called SSL Termination in this case :

The proxy server/load balancer we use for the SSL offloading acts as the SSL terminator. When a client attempts to connect to Datafari, the client still has a secure connection with the SSL terminator, which is acting as a pass-through.
The Datafari architecture is like this for monoserver and multiservers :

Architecture Apache reverse proxy monoserver

Architecture Apache reverse proxy multiserver

This solution is a good compromise between the secuirty and the maintenance. The network part between the load balancer and the Datafari servers can be more secured by isolating the servers by their own VLAN or IPSEC tunneling for example.

By using VLAN, we avoid all broadcast attacks like ARP cache poisoning, DHCP spoofing, smurf attack,, MAC table overflow, etc …)

According to section 4.1 of the PCI Data Security Standard any merchant handling credit card data should:

"...use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”

This means that Front End SSL is allowed, as once the data reaches the load balancer, it is considered to have entered a secure private network.