Overview
Configuring applications to remain unencrypted poses several security risks as user data traverses over networks in cleartext. Although it is widely accepted for utilizing https over the public internet, in most cases configured at the load balancer, configuring internal SSL communication is just as critical as you look to harden your systems, and drive toward a zero-trust network. Utilizing an internal Certificate Authority (CA), rather it be root or subordinate, can help you validate and certify your internal communication.
Utilizing LoadBalancer Termination
Despite being able to set TLS encryption at the load balancer, utilizing unencrypted traffic to the application tier still poses a risk. To display this, create a load balancer which targets an HTTP web app. For this example, I created a simple app fleet that just returns a 200 on any post.
Once set up, send a POST to the app server, while running tcpdump.
curl -X POST -d '{"data": "unencrypted" }' https://test.example.com
As you can see, the body is visible, and despite the certain network protections AWS provides within your VPC, technologies such as traffic mirroring, or application vulnerabilities such as command injection, could put you at risk of more than just your application seeing this data.
However, utilizing an encrypted backend this would not be the case:
curl -X POST -d '{"data": "unencrypted" }' https://test.example.com
Host to Host Communication
In other cases where load balancers are not involved, there may be use cases where your servers have to speak directly to each other. Once your web applications have their signed certificate from a private CA, it is as simple as adding that CA to the host trust, which will allow you to enforce validation when sending data.
Implementation
This example will define how to certify Nginx, however, a majority of these steps can easily be modified to whatever framework you are utilizing.
Note: The CA infrastructure will be built with Cloudformation, although AWS CLI commands will also work. At the time of writing, this is not available to do directly with native terraform resources: See Issue
Create a Private CA with ec2.internal domain or with your own internal host domain.
Create a certificate and activate the CA.
Utilize openssl to generate a key and csr.
Utilize issue-certificate and get-certififace acm-pca api calls to obtain the ssl_certifacte you will need to secure your internal domain. You will need the root CA ARN from created above.
Update Nginx, security groups, load balancer target groups, and/or hosts to listen and communicate with SSL.
Nginx
Security groups
Target Groups
Host
The following process will vary per Operating system. You should see this a guidance, but defer to your OS documentation for how to update the trust.
Latest comments (1)
concise explanation and good code examples. thanks dan!