HTTP listeners force clients to communicate in plain text, exposing all communications to any machines with connectivity to the traffic route
An AWS Elastic Load Balancer (ELB) serves as the entry point for incoming traffic to your applications. As the primary interface for external connections, an ELB can be configured to encrypt and decrypt client traffic, ensuring secure communication and verifying the server’s authenticity through TLS certificates. This process helps establish trust by matching the domain name to a valid, trusted TLS certificate and enforces that all communication is encrypted so that each client / server session transmits data privately.
Without TLS encryption, all communication between clients and the load balancer occurs in plain text. This exposes all of the communications to interception by any intermediary with access to the traffic from the Load Balancer through to the end client, this would include:
By neglecting to enable TLS, not only is the confidentiality and integrity of the data compromised, the server also fails to provide cryptographic proof that the service is legitimate via the TLS chain of trust. TLS certificates, issued by trusted Certificate Authorities (CAs), validate that the server is authorized to serve traffic for the specified domain.
Insecure, plaintext communication leaves your users vulnerable to eavesdropping, data tampering, and man-in-the-middle attacks, as any intermediary can view or alter the transmitted data.
The HTTP listener will need to be replaced with a TLS listener. This can be provisioned alongside the current listener and then redirects added to replace the current HTTP listener to redirect to the new TLS listener.
Provisioning a HTTPS listener needs a domain for your service and a TLS certificate that the load balancer listener can use. Once a domain is available you’ll be able to obtain a TLS certificate for the domain, ideally through AWS Certificate Manager (ACM), or uploaded to ACM when purchased from an external provider. Once the certificate is in ACM the HTTPS listener can be configured touse this new certificate.
Once the certificate is available and the listener fully provisioned then the HTTP listener can be replaced with Elastic Load Balancer redirect rules or the application itself can redirect non-HTTP traffic to HTTPS.
This setup applies to the majority of use cases, though there are exceptions. If your application initially accepts HTTP traffic but immediately redirects to HTTPS, then your service has the correct functionality already and AWS load balancers do not need to configure a redirect on the HTTP listener. However, it may still be beneficial to utilise the HTTP redirect functionality on the Load Balancer as this simplifies your architecture by offloading the task to AWS, reducing the additional logic within the application to handle HTTP redirects.
In cases where you use protocols other than HTTP, encryption methods should still be applied to protect data. If you’re unsure then our automated tools can analyse what protocols are in use by your endpoints and what security compromises need addressing:
SkySiege Cloud Security Assessments scan for this issue and provide same-day reports..
Available for individual projects or organisations.
