Using Elastic Load Balancer, it is easy enough to set up SSL at the external load balancer, and serve requests up as http to the applicaion.
When running a single server, it is also possible to configure SSL at the web server (Tomcat) or application (Spring).
When running with the load balancer, is it necessary to pull SSL up to the level of the load balancer? Is there an element of state to the SSL connection that will be lost by forwarding the still-encryped traffic?
Answer
I'm afraid that the answer will be "it depends". I had occasion to dig into it a bit when I was working with internet banking security. This was a couple of years ago, though, so it's entirely possible that someone else will come up with something that I forgot or that's changed during those years.
Disadvantages with terminating SSL at the load balancer
First, it's possible to lose state by doing this - if you have an application running that requires some SSL headers to keep state. If so, you are likely to lose that information (though you may be able to configure your load balancers to forward it in some manner). One example could be if you're using client certificates for authentication.
Second, as Bazze says, it does make your traffic vulnerable to eavesdropping on the local network. How much of a danger this is will of course depend on what your network looks like, and also what kind of traffic it is.
Advantages
You're reducing the load on your webservers, since they no longer need to spend their resources on decryption and encryption.
When you change your webserver configuration, you can do a simple apache reload without having to enter your SSL key password. This means that you can automate it, enabling continuous deployment and devops and all the buzzwords. (The flip-side to this is that changing your LB configuration may require you to enter the password, but as a rule that's something you don't do as often as fiddling with apache config...)
Troubleshooting your webserver and application just got a whole lot easier, since you can now snoop/tcpdump the incoming traffic directly.
You have fewer places to deal with SSL bugs/security holes. It's usually a lot easier to change SSL settings on one LB than on a large number webservers - especially if those servers are managed by lots of different people from different departments.
Auditing SSL is also a lot easier when there's only one place to audit.
It's a lot easier to keep track of what certificates are in use and when they need to be renewed when they're all in one place. You no longer have the issue of Bob having ordered a cert and put his personal email address in the system for reminders, and then quitting or getting fired so that the reminder bounces and the cert expires and suddenly you have a lot of upset people demanding that it get fixed Right Now! (Not that that has evere happened anyplace I've worked! cough)
Conclusion
Whether it's a good idea to terminate at the LB or not will depends on how you value the various advantages and disadvantages. As a rule, I'd say that unless there is a good reason to do otherwise, you'll want to remove complexity as early as possible - at the network border if that's reasonable from a security and usability standpoint, or as soon thereafter as possible.
No comments:
Post a Comment