Elastic Load Balancing is feature within AWS that disperses incoming traffic across multiple, healthy targets and increases the availability of your application and networks. To enhance the security of your Application Load Balancers (ALBs) and Network Load Balancers (NLBs), you must ensure that all load balancers that accept HTTPS traffic require, at a minimum, TLS 1.2. Older versions of TLS or legacy SSL protocols are known to have fatal security flaws and do not provide protection for data in transit.

In this demo, we will show you how to analyze HTTPS listeners and security policies to verify if load balancers support TLS 1.2.

For a visual guide on all things related to cipher suites, watch the full demo. To learn more about TLS security policies, read here. 

First, a brief diagram to show how things are set up in our lab. We have Route 53 resolving our test domain. That is pointing to an AWS Application Load Balancer. The communication from the load balancer is sent on to either of two Apache webservers both running on EC2. That communication is using HTTP between the load balancer and the webservers. The Application Load Balancer is accepting only HTTPS traffic and the TLS session is being terminated on the load balancer itself. 

To show our configuration of the load balancer, here is our load balancer going to our webservers-targetgroup. We can see that it only has a listener on port 443 and that it is using the ELBSecurityPolicy-2016-8. This is the default security policy that comes up with an Application Load Balancer. To see the settings that are enabled by that policy, we go to the AWS documentation for Elastic Load Balancing under “Create an HTTPS Listener.” We can see that this policy supports TLS version 1, 1.1, and 1.2, as well as a wide selection of cipher suites. To demonstrate that things are working, we’ll refresh our page until we see both webservers here. We see Webserver-2 and Webserver-1 showing up on our test page. 

We’ll also look at an SSL Server Test and we see that SSL Labs has capped this particular grade at a B, given that it is supporting both TLS 1.0 and 1.1 in addition to TLS version 1.2. We should never just look at this up here and say, “Ooh, a B, that sounds great!” We should also scroll down and look at the details. In this case, we’ll scroll down and see that TLS 1.0 and 1.1 are both supported, in addition to 1.2. SSL versions 2 and 3 are not supported. We can even see the cipher suites that are supported through this. One thing that is nice about SSL Labs is they give you this “Handshake Simulation.” What type of connection would be made by different types of devices? We can see, for instance, “IE 7/Vista,” neither of which are supported, obviously, will only be able to make a TLS 1.0 connection and so on and so forth. We can see different types of “Handshake Simulations,” whether or not a connection will be successful, and to what version of TLS the connection will be made to. 

Now, let’s change our configuration to support a better version, here – a more secure version. As we know, TLS 1.0 suffers from several fatal flaws. TLS 1.1 can be configured around those flaws, but especially with wide support for TLS 1.2 and even for TLS version 1.3 coming out, we should really think twice about even supporting TLS 1.1 at this point. Let’s configure our load balancer. Editing our security policy, we can see here that we have several choices. We’re going to scroll down until we see, specifically, this one right here. This says that it supports forward secrecy version 1.2 for TLS, restricted cipher suites, and then the date which this policy was created. We will update that and we see that we have successfully modified this listener. 

Come back over here to our webpage, refresh a few times, make sure that we’re getting to both webservers, sure enough Webserver-1 and Webserver-2 are showing up. Then, look at an updated version of SSL Labs run after our change and we see that it is now graded at an A with “Protocol Support” being all the way up to the top, scoring 100 out of 100 on that. Scrolling down to see the details, we see that we do only support TLS version 1.2. These other ones are all “No.” Our limited set of cipher suites, specifically SSL Labs is complaining because we do support CBC mode (cipher block chaining mode) in AES. It is a good practice to disable cipher block chaining mode wherever possible, regardless whether it is AES, 3DES, Camellia, or any other block cipher being used there. CBC mode is not favored in TLS connections. But we do have a significantly more secure TLS configuration, supporting only TLS 1.2 with strong ciphers. If it is necessary to support a wider cipher suite set, then we can also select this right here, ELBSecurityPolicy-FS-1-2-2019-08, without the restricted tag on that. This will support only TLS version 1.2 while also supporting a slightly wider set of ciphers.