All the rage these days is adding encryption to EVERYTHING.  For anything internet-facing, I wholeheartedly agree that it needs to be encrypted, and that encryption should use the latest technologies available.

There are a lot of back-end services that use network connections to operate.  A primary one is webapp servers, and some other examples are databases and search engines that a public website needs to access.  There is a lot of demand and effort for encryption and other security features on these connections.

In my opinion, these services should not be exposed to ANY untrusted parties at all, and definitely should not be exposed to the open Internet.  If that advice is followed, there’s no need for encryption, and for some kinds of services, not even any need for other security features.

For software where encryption is extremely easy to add and all the hardware involved on both sides of the communication is capable of accelerating encryption processing in hardware, encrypting those back-end services can make sense.  But for a lot of services, it’s overhead and configuration complexity that just doesn’t make sense.

A common complaint that I hear at this point in any security discussion is “I don’t want people to be able to sniff my back-end traffic.”

Let’s examine that a little.  Exactly what would a hypothetical attacker have to do to be able to sniff unencrypted traffic on a back-end server in a typical networking situation where there is no direct access?  In most cases, they have to either compromise one of your Internet-facing services, usually a load balancer like haproxy or nginx, or a webserver like Apache httpd, nginx, Tomcat, or many others, or they need to have physical access to your infrastructure.  If an attacker compromises one or more of your Internet-facing services and gains full administrative privileges on the machine, they are going to have access to everything that machine knows, and chances are that it has ALL the keys to the kingdom.  If they have physical access to your hardware, there’s pretty much no limit to what they can access and the problems they can cause for you, and very little you could do about it.  Security features like authentication and encryption won’t matter, the attacker will simply get what they need from what they’ve already compromised, and they’ll have access.

I still support efforts to enable encryption in virtually all network-based software, as long as that support is VERY easy to get working.  Some services allow encryption but present significant technical challenges for it to be correctly implemented.  This is particularly the case if the software is written in Java — Java’s system for handling certificates is clunky and error-prone.  For that kind of backend service, if it is not directly reachable from the Internet, it might make more sense to leave it unencrypted.  A few Java programs do handle the PEM certificate and key format, which is typically what you get from a CA and is the default format for virtually all non-Java software.