Is there any Security issue if we not used SSL between AWS Cloudfront and AWS ALB?

Question

I have an application that is hosted on AWS. It has an Application Load Balancer in its front and it is also attached to the Cloudfront to handle a heavy load. In my case, I have enabled SSL only on Cloudfront and haven't had SSL on ALB. Now the application works fine without any issue. It is showing a secured lock symbol on all browsers. But I had a feeling that the communication between the CloudFront and ALB is not secure. Anyone who tries to intercept the traffic between them can achieve it.

Is there any security risk like that? Can anybody intercept the traffic or all communications inside AWS are secured?

I heard about the SSL offloading feature of AWS ALB where we are not enabling SSL between ALB and EC2 servers behind it. I thought this case is also applicable between Cloudfront and its origin ALB. Is that correct or is there any security issue if we doesn't enable SSL between Cloudfront and ALB.

Answer 1

TLDR: if you are dealing with your own application, many issues should have a higher priority than this; if you are dealing with security auditors, yeah, most likely you will need SSL cert for ALB.

---

It's up to what kind of risk you can accept. Some government projects don't allow any risk from internet, so they are in intranet.

Before we start, you should create the security group on your ALB to only accept CloudFront Edge IP. You can get the ip ranges from here: https://ip-ranges.amazonaws.com/ip-ranges.json

AWS also published one guide previously, https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/

Back to the topic, we first need to know what kind of risk there before we decide whether it's a concern.

One legit concern is what if someone sniff my HTTP traffic between Cloudfront and ALB.

Below are quoted from AWS.

CloudFront maintains a pool of persistent connections to the origin, thus reducing the overhead of repeatedly establishing new connections to the origin. Over these connections, traffic between CloudFront and AWS origins are routed over a private backbone network for reliability and performance. This reduces overall latency for serving both static and dynamic content. https://aws.amazon.com/blogs/networking-and-content-delivery/dynamic-whole-site-delivery-with-amazon-cloudfront/

So some will ask what does "private backbone network" mean?

Traffic traverse our infrastructure rather than the internet Slide 23, https://www.slideshare.net/AmazonWebServices/behind-the-scenes-exploring-the-aws-global-network-net305-aws-reinvent-2018

All data flowing across the AWS global network that interconnects our datacenters and Regions is automatically encrypted at the physical layer before it leaves our secured facilities. https://aws.amazon.com/about-aws/global-infrastructure/

So if AWS doesn't mess up, the traffic between cloudfront edge location and ALB servers are secured. It's within AWS private network backbone and encrypted before leaving AWS secured facilities.

If AWS messed up, yeah, i think you will have a much bigger problem than this SSL issue.

Answer 2

I would say the short answer is: a compromise is possible.

It would seem that defense-in-depth applies here. Not using SSL assumes that the environment is completely trustworthy and secure, and always will be. Such an assumption has lead to many incidents.

Put another way - there is no risk assuming that all of the following is always true:

1. you do - and always will - fully control and trust the VPC that hosts it;
2. that you do - and always will- fully control and trust all the instances involved (and new ones that may be introduced);
3. that you do - and always will - fully control and trust all the traffic that will ever traverse the VPC;
4. that you will never have an incorrectly - or maliciously - configured perimeter control;
5. that there will never be a vulnerability in any of the components that could lead to man-in-the-middle or other types of compromise;
6. that the environment will never be exposed to any malicious actor (individual or software);
7. that there is little-to-no potential loss if the systems or information involved are compromised, damaged, or lost.

Since it would be unlikely that one could say with certainty that all of the above will always be true, it is usually wise to use encrypted communications at all times. Given that the functionality is readily available, and the overhead impact is negligible, it would seem best to simply use it.