NLB SSL termination enables centralized SSL certificate deployment by integrating with AWS Certificate Manager (ACM) and Identity Access Manager (IAM). At Bobcares, with our AWS Support Service, we can handle your NLB SSL Increment issues.

NLB SSL termination

Elastic Load Balancing now supports TLS termination on Network Load Balancers. Our ability to offload the decryption and encryption of TLS traffic from our application servers to the Network Load Balancer thanks to this new feature allows us to increase the efficiency of our backend application servers while maintaining the security of our workloads. Additionally, while terminating TLS on the load balancer, Network Load Balancers maintain the source IP of the clients to the back-end applications.

We can configure encryption optionally for the targets. Additionally, this feature gives us the flexibility of predefined security policies, allowing us to manage the cyphers and protocols that the load balancers show to our clients and thereby ensuring a high level of security for our applications. Both AWS CloudFormation and AWS PrivateLink are fully compatible with TLS termination on Network Load Balancers.

A lot of interesting work, formally known as an SSL/TLS handshake, occurs when we access a website using the HTTPS protocol in order to establish and maintain a secure communication channel. Together, our client (the browser) and the web server negotiate a mutually beneficial cypher, trade keys, and establish a session key. Once established, we can use the session key by both parties to encrypt and decrypt all subsequent traffic. A third party cannot decrypt the traffic or interfere with the conversation because the session key is specific to the conversation between the client and the server.

New TLS Termination

By enabling us to use TLS (Transport Layer Security) connections that terminate at a Network Load Balancer (we can think of TLS as providing the “S” in HTTPS), we are today making the process of developing secure web applications more straightforward. This will give us a number of additional features and advantages while also relieving our backend servers from the computationally demanding task of encrypting and decrypting all of our traffic:

Source IP Preservation

Even if we terminates the TLS at the NLB, the source IP address and port are sent to our backend servers.

Simplified Management

We must assume responsibility for providing our server certificate to each backend server in order to use TLS at scale. Due to the multiple copies of the certificate, this increases our attack surface and adds additional management work (sometimes requiring a fleet of proxy servers). With today’s launch, all of that complexity is gone and we now have a single location where we can manage all of our certificates. If we use AWS Certificate Manager (ACM), our certificates will be securely stored, regularly rotated and expired, and automatically updated—all without any intervention on our part.

Zero-day Patching

The TLS protocol is intricate, and implementations are periodically updated in response to new threats. By cutting off our connections at the NLB, we can defend our backend servers and update our NLB to counter these threats. We employ s2n, our security-focused, officially validated TLS/SSL implementation.

Improved Compliance

To specify the cypher suites and protocol versions that are acceptable for our application, we can use built-in security policies. This will support our efforts to comply with PCI and enable us to receive a perfect TLS score.

Classic Upgrade

Changing from a Classic Load Balancer to a Network Load Balancer will enable us to scale more quickly in response to an increased load if we are currently using a Classic Load Balancer for TLS termination. Additionally, we will be able to log the source IP address for requests and use a static IP address for our NLB.

Access Logs

Our Network Load Balancers now have the option to enable access logs and direct them to the S3 bucket of our choice. In-depth details about the TLS protocol version, cypher set, connection and handshake times, and other details include’s in the log entries.

Using TLS Termination

In a matter of minutes, we can build a network load balancer and use TLS termination. The CreateLoadBalancer API, Create-Load-Balancer CLI, EC2 Console, or an AWS CloudFormation template are all options.

1. Firstly, we’ll access the Console.
2. Then click Load Balancers.
3. Then, in the Network Load Balancer section, click Create.
4. Choose TLS (Secure TCP) as the Load Balancer Protocol and give it a name (MyLB2).
5. Then, optionally, we select one or more Availability Zones and an Elastic IP address for each. I have the option of tagging my NLB. Once everything is ready, we can click Next.
6. Configure Security Settings after that to continue.
7. Then We can select an existing certificate or upload a new one on the following page.
8. Then select a security policy next. Right now, there are seven security policies to pick from. Every policy permits the use of specific TLS iterations and cyphers.
9. Finally, click the Next:Configure Routing button. We have the option to use of selecting the communication protocol (TCP or TLS) between NLB and targets. We can use full end-to-end encryption in transit when using TLS, which encrypts all of our communication during transmission.

We can use my Network Load Balancer right away after the remaining setup steps go according to plan.

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, using more expensive application load balancers was previously required for TLS termination at the load balancer step (ALBs). To improve security and cut costs, AWS introduced TLS termination for network load balancers (NLBs).