Continually Enhancing Domain Security on Amazon CloudFront

Last year, a colleague of mine wrote a blog post about new security measures that Amazon CloudFront was implementing to enhance the security of how domains are used on CloudFront distributions. This included mitigations to prevent the abusive use of domain fronting practices by not allowing SSL handshake requests and subsequent requests over the secured HTTP protocol to be made between two unrelated accounts. That work also included new mechanisms to clearly warn customers about inadvertently creating “dangling” DNS entries (which could lead to other security concerns) when they are removing an alternate domain name or deleting a CloudFront distribution, but their DNS records were still pointing their domain traffic to CloudFront.

In hindsight, the “dangling DNS” warnings were relatively easy to implement, but the domain fronting issue turned out to be a bigger challenge than expected. The challenge came in the form of automatically distinguishing between legitimate and abusive uses of domain fronting, and doing so at the massive scale at which CloudFront operates with its global network and large customer base. Additionally, we knew we had to accomplish this without impacting the end viewer experience with increased latency.

Just a short while ago, CloudFront deployed its new code change for handling domain fronted requests. This new code ensures that the AWS account that owns the SSL/TLS certificate which established the secured connection via a SSL handshake is the same AWS account as the subsequent requests made over the secured HTTP protocol. If the two AWS accounts do not match, CloudFront will respond with a “421 Misdirected Request” response to give the client a chance to connect using the correct domain. We believe that this will provide the flexibility that customers need to continue using this technique for legitimate use cases while also providing enhanced protection knowing that their domain cannot be touched by an unrelated AWS account.

Earlier today, CloudFront announced an additional security enhancement that changes the way alternate domain names are added to a distribution. This new functionality enhances the security of how domains are used with CloudFront and this blog provides additional insight into the validation mechanism behind this change.

Securely adding alternate domain names (CNAMEs) with CloudFront

Before diving into the details, it is important to clarify that a CloudFront alternate domain name (CNAME) is not the same thing as the authoritative DNS domain name or canonical name, also known as a CNAME. These two entries are related by nature of establishing a link between two different entities, but each entry is separate and distinct from each other. The CloudFront alternate domain name (CNAME) on a CloudFront distribution allows you to serve your content using a custom CNAME from your DNS records, such as www.example.com, instead of the default domain that CloudFront assigns, such as d123456abcdef8.cloudfront.net. Only the CNAME from your authoritative DNS records actually controls where your domain’s traffic is pointed to and from which endpoint your traffic will be served to your end users.

When adding an alternate domain name to CloudFront, we have always checked that the CNAME did not already exist on another distribution, or that it did not fall under the umbrella of a wildcard alternate domain name that exists in another account’s distribution. If the alternate domain name is not available for either one of these reasons, customers are asked to contact AWS Support and prove ownership of their domain. This is done by the customer creating a new DNS TXT record entry before they are given rights to use that alternate domain name.

Today’s change further enhances the security of CloudFront’s domain validation process. Starting today, when you add an alternate domain name by using the AWS Management Console or the CloudFront API, you must also attach a SSL/TLS certificate to that specific distribution in order to validate that you have authorized rights to use that alternate domain name. This is designed to ensure that only customers with authorized access to a domain’s certificate can add alternate domain names to use with a CloudFront distribution.

New validation checks when adding an alternate domain name

The vast majority of the Internet’s traffic, as well as CloudFront’s, is encrypted using the SSL/TLS protocol and SSL/TLS certificates are a central part of that process. Getting a certificate to use the secured protocol has never been easier. This is especially true with the launch of AWS Certificate Manager (ACM) in 2016, which allows a customer to provision a public certificate for free.

CloudFront’s process to validate a customer’s right to use an alternate domain name builds on the already established and trusted checks in place for obtaining a certificate. No one can obtain a valid SSL/TLS certificate without first proving that they own the domain by either entering a unique entry into their DNS records, or validating the request for the certificate via email to the domain owner. Rather than having customers go through a redundant process to re-validate their ownership, CloudFront will now simply require that a certificate be attached to that distribution when adding an alternate domain name to the distribution.

This certificate must be valid in relation to the ‘Valid from’ and ‘Valid to’ dates, and it must also be issued by a publicly trusted Certificate Authority (CA), such as ACM. If you do not choose to use ACM, any certificate issued from a CA listed on the Mozilla Included CA Certificate List will work as well. The certificate must also include the alternate domain name being added to the distribution in the subject alternate name (SAN) field of the certificate – either by an explicit match, or a wildcard at the same level of the alternate domain name being added.

For example, let’s say you own the domain foo.com and want to receive your web traffic on a CloudFront distribution with the alternate domain name www.example.foo.com. Let’s also assume you obtained a new certificate from ACM. In order to add this alternate domain name to your distribution, your certificate would need to either list the exact match www.example.foo.com or *.example.foo.com. It is important to note that wildcards will only cover the alternate domain names at that same level and not anything at levels lower or higher than the wildcard. In this example, the wildcard *.example.foo.com would not cover alternate domain names such as one.www.example.foo.com or example.foo.com. This logic of what alternate domain names a wildcard can cover aligns with how web browsers handle certificates today when establishing trusted, secure connections.

Once these validation checks have been met, CloudFront will then instantly add that alternate domain name to the CloudFront distribution.

What actions are required?

All alternate domain names already added to a CloudFront distribution before this change will continue to work as they were before. No action is needed to maintain your existing traffic as it is today.

These validation checks come into effect each time you add a new alternate domain name to your distribution. These checks are also only performed for the new alternate domain names that are being added.

If you use CloudFront APIs for an automated Update/Create Distribution action, it is important to note that versions dated 2012-07-01 or earlier will not be capable of adding a CNAME because they do not have the ViewerCertificate field required to pass these checks. As a result, we recommend updating using the latest CloudFront API version 2018-11-05.

For additional details, please refer to the updated CloudFront’s Developer Guide. You can also find resources to help troubleshoot any issues in the AWS Knowledge Center.

As always, security is our top priority, and we will continue to make enhancements to our services to protect our customers.