I guess that "terminating TLS/SSL on the EC2" doesn´t include the option to "terminate the TLS/SSL" on the LB and then re-encrypt the communication again towards the EC2. It might be worth to point that out on the lecture, since the ALB is capable of doing that.
When terminating the TLS/SSL on the EC2 using a Classic ELB, you need to configure a TCP Listener and a TCP Instance Protocol, right?
When terminating the TLS/SSL on the EC2 using a NLB, you need to configure a TCP Listener and a TCP Target Group, right?
5 Answers
Yes you have to setup a TCP listener on the target (always). In case you are terminating on TLS EC2 – you will also have to setup the certs on EC2.
Earlier you could Not terminate TLS on NLB now (very recently) you can.
There is nothing called "TCP Target Group" , you have "target type" – IP and Instance
Hi, did you see somewhere in the documentation that the ALB is capable of re-encrypting the traffic? I would be interested to see that,
thanks
Faye
I always thought that terminating the SSL at LB and re-encrypting the traffic up to the EC2 level is good practice. If SSL is terminated at LB level, LB can do LBing on many other factors such as sticky sessions/or based on the application URL.
Also, traffic from LB to EC2, if it is not re-encrypted, it goes through the logically isolated channel to reach EC2 instance and it is not physically isolated. Considering the number of vulnerabilities at different layers and in the protocol level, I always consider re-encrypting again is good practice. I agree you will incur additional processing and complexities because you need to maintain the certification at different levels.
I agree with Raksha… there is a specific use case of terminating on the LB and re-encrypting. If the load balancer does not terminate, it can not balance load based on sticky sessions or URL so if that feature is needed and the traffic is encrypted the load balancer must be capable of decrypting the traffic.
I agree with @lulon83 and paul. It is definitely possible to re-encrypt the traffic at the ALB level.
However, it seems not to give the desired security assertions:
"Amazon’s ALB’s do not validate TLS certificates from internal services" [1]
"You’re right that ALB does not validate the certificates on targets, but it’s important to understand the context that ALBs run in to see why this is still a pending item on our roadmap, rather than something we’ve shipped already as a “must have”." (AWS’s response to ALB internal validation failures) [2]
"Also, there is a feature request in place for backend server authentication on ALB. However, I can’t guarantee that the feature will be implemented or provide any ETA regarding it." (AWS Support) [3]
I don’t know… did anyone see this is already shipped? I could not find any evidence they implemented certificate validation. This makes the whole re-encryption relying on the VPC infrastructure rather than PKI only.
[1] https://kevin.burke.dev/kevin/amazons-albs-insecure-internal-traffic/
[2] https://kevin.burke.dev/kevin/aws-alb-validation-tls-reply/
[3] https://forums.aws.amazon.com/thread.jspa?threadID=263914
If you configured the ALB with HTTPS Listener and HTTPS Target Group… wouldn´t the ALB re-encrypt the traffic to send the requests to the EC2?
Consider a use case where you are using certificate based authentication from the client and the validation of the cert needs to be done by application.
If you terminate at ALB, you will then effectively use the ALB’s cert to encrypt and send data to EC2. This effectively breaks the "pass though" and end-to-end ecryption. Moreover the client certificate sent by the client will not reach the Application.
See Routing Configuration here: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html
Hi Faye, both ALB and NLB are able to re-encrypt the traffic. Here are 2 quotes. "I can choose the communication protocol (TCP or TLS) that will be used between my NLB and my targets. If I choose TLS, communication is encrypted; this allows you to make use of complete end-to-end encryption in transit." Quoted from: New – TLS Termination for Network Load Balancers https://aws.amazon.com/blogs/aws/new-tls-termination-for-network-load-balancers/ "If a target group is configured with the HTTPS protocol or uses HTTPS health checks, the TLS connections to the targets use the security settings from the ELBSecurityPolicy-2016-08 policy. The load balancer establishes TLS connections with the targets using certificates that you install on the targets." Quoted from Target groups for your Application Load Balancers https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html
Actually, there is another blog posted in 2011 talking about this https://aws.amazon.com/blogs/aws/elastic-load-balancer-ssl-support-options/ "You can now terminate SSL sessions at the load balancer and then re-encrypt them before they are sent to the back-end EC2 instances."