AWS Network Load Balancer SSL passthrough

Question

I'm trying to secure full e2e connection between clients and my backend servers. This is how my current infrastructure looks like:

1. Fargate cluster with my backend apps placed inside private subnets.
2. They are fronted by internal network load balancer which is also not exposed to the outside world.
3. REST API Gateway with VPC link integration to my internal NLB.

Currently my NLB is using TLS listener on port 443 and have certificate attached but is terminating the TLS and communicating with its target group limply by TCP on port 80. My plan is to configure TLS and certs also on my Fargate nodes. Currently I lack the understanding of how the following setup would work. Is it going to send encrypted traffic from my clients to backend apps or rather perform decryption at the NLB and encrypt the traffic one more time before sending it to the Fargate nodes ?

I have learn reading many blogs that it is possible to achieve a passthrough behavior using NLB without decrypting/encrypting the traffic on NLB but didn't find any examples, also AWS documentation is not clear about this topic.

It is possible to have certificates applied only to my backend apps and have decryption happening only there ? My understanding is that I could look similar to below:

1. Certs and TLS configured at my Fargate apps side
2. NLB with TCP listener on port 443, no certs applied on NLB level. So the NLB would only pass the encrypted traffic from my clients to the backend.

Does anyone tried setting up similar infrastructure and have some knowledge on how this should be configured ?

Regards.

Answer 1

I believe your assumption is right, Jarek. You need to create an NLB with TCP Listener on 443 and TCP TargetGroup as well. The ECS container you deploy (Fargate or whatever) will be the one receiving the TLS request, performing the handshake negotiations etc. Your NLB listener is really a TCP pass thru, if you will on port 443, and the ECS container does the actual TLS work. For the ECS container, you'd probably want to use SecretsManager to store your cert, key and chain.

If you're also needing client cert validation (mTLS), you'd also want to store any any additional chains you might need for client cert validation.

The drawback to doing this NLB setup is that you lose some of the features of NLB TLS listener, such as the TLS Protocols restrictions that it can enforce. You can do this on your ECS container yourself, but the container does become more complex.

One caveat to be aware of is the the "preserve client IP" functionality that the TargetGroup can perform will break your target group. Haven't figured a way around that yet. So far, haven't been able to make that work with this setup.

Additionally, I suspect there is a way to create a TLS Listener matched with a TLS TargetGroup with TLS enabled ECS container, but to me this seems redundant and difficult to configure right since decryption would happen at the NLB then it would re-encrypt for the TLS TargetGroup and ECS Container. I'm not exactly sure how that might work, if at all. My understanding is that the AWS ELBv2 ALB and NLB are not validating any TLS certs behind them (ref needed). I haven't personally been able to get this working right though.