Do You Use SSL between Load Balancers and Servers?
One of my readers sent me this question:
Using SSL over the Internet is a must when dealing with sensitive data. What about SSL between data center components (frontend load-balancers and backend web servers for example)? Does it make sense to you? Can the question be summarized as "do I trust my Datacenter network team"? Or is there more at stake?
In the ideal world in which you’d have a totally reliable transport infrastructure the answer would be “There’s no need for SSL across that infrastructure”.
On planet Earth I wouldn’t worry that much about the networking team but more about servers from multiple applications sitting in the same L2 subnet (ideal scenario for an intruder trying to move laterally).
Also, I would ask the question "Is data encrypted at rest?" and when the answer is "NO" the next question should be "and why do you trust shared storage infrastructure more than shared network infrastructure?".
Finally, SSL within the data center usually protects the data exchanged between the load balancer and the web servers. While that data definitely deserves protection, there’s an even more important data stream: data exchanged between the web servers and the database servers. Are you encrypting the database connections? If not, why do you worry about encrypting web sessions?
The same reader also sent me a follow-up question:
If I understand you correctly, if servers are on the same unprotected L2 segment, encryption would then make sense. I suppose that if we go on that path, each server should have its own certificate (or at least each application). Otherwise, having same certificate on all wouldn’t give more protection as breaking in one server would give you access to the private key. Am I right?
If you’re serious about security, you should have a different certificate for each application. You should also use Ephemeral Diffie-Hellman key exchange.
Few Details
It’s really easy to decrypt a lot of TLS (formerly known as SSL) traffic if you have the server’s private key. Many TLS key exchange algorithms use a simplistic approach:
- Client generates a random session key;
- Client encrypts the session key with server’s public key;
- Server decrypts the session key using server’s private key.
Once you have the server’s private key, you can decrypt the session keys, and subsequently all traffic exchanged with that server (that’s why you can decrypt HTTPS traffic with Wireshark).
Some TLS key exchange algorithms provide forward secrecy: it’s impossible to get the session key (and subsequently encrypted data) even if you have the private keys. These algorithms rely on Diffie-Hellman key exchange, more specifically on ephemeral DH where the session key is generated for every TLS session.
For more details, do spend some time reading the Wikipedia TLS article.
Encrypt everything. Crypto is cheap and fast now, I don't see why you wouldn't.
So it depends on if your DC is trustworthy or not. If not, then definitely use SSL
We need to stop pretending that we are doing this well.
It's also worth mentioning that we pay one (actually small) fee for unlimited certificates and can generate one in about 5 minutes. Our entire infrastructure team is pretty well practiced in getting real SSL certs generated and installed.