Securing Amazon API Gateway with secure ciphers using Amazon CloudFront

Enterprise customers have differing requirements based on a number of reasons including security, compliance, governance, and the industry they operate. In certain situations, customers are expected to adhere to certain protocols and standards that are non-negotiable. In this post, we explore how customers can specify TLS protocols and associated ciphers that are allowed from viewers on Amazon API Gateway.

The TLS protocol provides protection against network security concerns, such as tampering between client and server communication. It is recommended to use the latest version of TLS to make sure that your API can support the most recent ciphers which offer the highest level of security. API Gateway provides numerous options for selecting TLS ciphers for the APIs provisioned for your custom domain. However, enterprise customers may require further flexibility based on their organizational policies and governance requirements.

This post is intended to assist customers in this particular situation to customize API Gateway endpoints to support specific TLS cipher suites that meet their organizational compliance requirements.

Walkthrough

What are Cipher Suites and how do they relate to TLS/SSL?

Cipher Suites are a collection of Cryptographic algorithms (Ciphers) that allow network connections to be secure. A typical TLS/SSL Cipher suite provides a set of steps and the order under which the contained algorithms are executed. A considerable amount of processing is involved when establishing the HTTPS connection between the client and server applications. This process is referred to as a TLS/SSL handshake. During the SSL/TLS handshake, the client application provides the server application with the maximum TLS version along with the cipher suites it supports. Then, the server application makes a decision based on the best options available for both the server and the client on the right TLS version and cipher suites to be used throughout the session.

Cipher suites for TLS 1.2 and TLS 1.3

TLS 1.2 and TLS 1.3 are the prevalent standards used today. The cipher suites for TLS 1.2 and TLS 1.3 are different, TLS 1.2 uses 37 cipher suites whilst TLS 1.3 uses only five cipher suites. TLS 1.3 is still considered more secure and the reason for this lies in how these cipher suites are created.

If you look deeper into the composition of a TLS 1.2 cipher suite, then you find the following four ciphers:

·      Key exchange algorithm for protecting information when creating symmetric keys for exchange

·      Signature algorithm which validates the type of certificate

·      Bulk data encryption algorithm to encrypt messages between client and server

·      Message authentication code (MAC) algorithm to perform message authentication using hashes and signatures between the clients and the server

An example of how the different algorithms in TLS 1.2 Cipher Suite are organized is shown here:

TLS 1.2 Cipher Suite Organization

Looking at the composition of the cipher suite for TLS 1.3, you notice only two ciphers: one for MAC and the other for bulk data encryption. An example for a TLS 1.3 Cipher is shown here:

TLS 1.3 Cipher Suite Organization

With TLS 1.3, the client-server TLS/SSL handshake doesn’t require negotiations for key exchange and signature. This reduces the messages exchanged during the TLS/SSL handshake to just one round trip in TLS 1.3 as compared to two round trips in TLS 1.2, making TLS 1.3 faster. TLS 1.3 is also safer than TLS 1.2, as it has removed support of older, weaker, and more vulnerable algorithms which were supported in TLS 1.2 and the previous versions of TLS.

TLS support in API Gateway

When implementing API endpoints for your organizational needs, you can utilize API Gateway to quickly provision different types of highly scalable APIs. The three types of APIs supported by API Gateway are REST, HTTP, and WebSocket APIs. You can create an API Gateway by following the steps mentioned in the AWS documentation. Security becomes a prime concern when it comes to exposing the created API Endpoints to the client applications. API Gateway allows developers to choose a minimum version of TLS protocol to be enforced on your custom domain to provide enhanced security. Adding the security policy is supported using either AWS Management Console, AWS Command line Interface (AWS CLI), or by using AWS SDKs. To create a custom domain for API Gateway,

1.     Log in to the AWS Console.

2.     Navigate to API Gateway console by either searching for API Gateway or traversing through the Services menu.

3.     In the API Gateway console, select “Custom domain names” as shown in the image below.

API Gateway- Create domain names

Currently, when creating the custom domain name, API Gateway provides options to choose a security policy between TLS 1.2 or TLS 1.0 as the minimum TLS version for the custom domain. The following image shows the TLS ciphers supported by an API with regional endpoint or a custom domain name with regional endpoint. Utilities like sslscan are effective at finding the TLS ciphers supported by the server.

TLS ciphers supported by an API Gateway with regional endpoint or a custom domain name with regional endpoint

API Gateway support for TLS 1.3

Currently, out of the box support for TLS 1.3 and its associated cipher suites occurs when deploying the API using edge-optimized endpoints or fronting the API using an edge-optimized custom domain name. In both cases, an AWS managed Amazon CloudFront distribution gets created using the security policy set by CloudFront, which has support for TLS 1.3 cipher suites. However, in both cases, since the CloudFront distribution created for the API is managed by AWS, it is not possible to customize the TLS version and the cipher suites used. Currently, the recommended (default) security policy for CloudFront distributions using custom SSL certificates is TLSv1.2_2021. The cipher suites supported with TLSv1.2_2021 and other security policies is highlighted in the AWS documentation for supported protocols and ciphers for CloudFront. The following image shows the TLS ciphers supported by an API with edge-optimized endpoint or using an edge-optimized custom domain name.

TLS ciphers supported by an API Gateway with edge-optimized endpoint or using an edge-optimized custom domain name

Exposing API Gateway via a custom CloudFront distribution

Organizations that need flexibility in selecting specific security policies and associated TLS ciphers benefit from using an API Gateway with a regional endpoint and fronting the endpoints via a custom CloudFront distribution. Doing this allows the organizations to not only select their preferred security policy and TLS ciphers, but also use additional features provided by CloudFront including choosing default cache behavior, selecting minimum origin SSL protocol, selecting the supported HTTP versions, and adding response headers to decide on the CORS policy to be used, among others. An example architecture to achieve this looks similar to the following.

Sample architecture showing CloudFront distribution in front of a regional API Gateway

Refer to the steps highlighted in the AWS documentation for CloudFront to create the CloudFront distribution. As per the previous architecture, placing the CloudFront distribution in front of a regional API Gateway lets us configure the right Security Policy with the needed TLS 1.3 ciphers to be allowed for communication from the clients to the CloudFront. The communication between the CloudFront and the origin (Regional API Gateway) will occur based on the minimum origin SSL protocol set between CloudFront and the Origin.

You can choose to limit the access to your REST Regional API Gateway endpoint exclusively to CloudFront by adding a custom header (X-Origin-Verify) to the request when CloudFront passes the request from client to API Gateway using AWS WAF in between, as highlighted in this AWS Well-Architected Lab. The same can be achieved with HTTP API Gateway endpoint using an API Gateway Lambda authorizer as highlighted in this post.

The following image shows the TLS ciphers supported by the custom CloudFront distribution fronting the Regional API Gateway endpoint with security policy selected as TLSv1.

TLS ciphers supported by fronting the Regional API Gateway endpoint with security policy as TLSv1

Limiting API endpoints to support only strong cipher suites

Now that we have achieved fine control on the level of security policies and associated cipher suites supported by CloudFront fronted API, let’s see how this can help organizations where API endpoints are required to support only strong cipher suites and not allow handshakes from clients publishing weak cipher suites.

To give a background for this use case, let’s first define weak and strong ciphers. A weak cipher is one where the algorithm used to encrypt/decrypt uses a key which is not long enough, thus making it vulnerable to attacks. On the other hand, a strong cipher uses an algorithm with a longer key, thus making it more robust. You can read more about strong and weak ciphers on the owasp site. Both regional and edge optimized API Gateway endpoints have support for weak cipher suites. This makes them inappropriate to be used in organizations which have a mandate of using API endpoints supporting only strong cipher suites.

The classification of cipher suites supported by regional API Gateway endpoints is shown in the following (source: ssllabs). Note that the Regional API Gateway endpoints support only TLS 1.2 as well as weak cipher suites.

Regional API Gateway endpoints support only TLS 1.2 as well as weak cipher suites

The edge optimized API Gateway endpoint falls in the same category as regional endpoints, where even though it supports TLS 1.3 along with TLS 1.2, it still has weaker cipher suites in the supported cipher suites. The classification of cipher suites in order of preference for edge optimized API Gateway endpoint is shown in the following image (source: ssllabs).

TLS version and Cipher suites supported by edge optimized API Gateway endpoint

To overcome this issue, you can use the same solution of fronting the API Gateway with CloudFront. To allow your API to use only strong cipher suites, you can configure a custom SSL certificate for the domain which can then be used as an alternate domain name for the CloudFront distribution, followed by selecting the Security policy to be the latest version. In this scenario, the security policy to be selected is TLSv1.2_2021 (recommended), as shown in the following image.

Selecting Security Policy to be used between CloudFront and clients

Looking at the classification of cipher suites where the endpoint custom domain is added as an alternate domain to the CloudFront distribution, you find that it has support for both TLS 1.3 and TLS 1.2, but it has limited its cipher suites to support only strong cipher suites. This makes the above arrangement of API Gateway fronted by CloudFront distribution with your custom domain name certificate with a security policy of TLSv1.2_2021 a perfect choice for organizations which require their API endpoints to support only the strong cipher suites for both TLS 1.3 and TLS 1.2. The following image (source: ssllabs) shows the classification of cipher suites for this arrangement.

TLS version and Cipher suites supported by API Gateway fronted by CloudFront Distribution with custom domain name certificate

Conclusion

In this post, we saw how fronting API Gateway with custom CloudFront distribution provides customers with the right control and flexibility to adjust the TLS versions and the associated cipher suites for their APIs to be compliant with their organizational policies. Furthermore, by using the needed TLS ciphers, the solution also enables customers to use other associated benefits with CloudFront not limited to added reliability, low latency, and high throughput network connectivity with the help of its global edge network.

Visit creating a CloudFront distribution and Amazon CloudFront Pricing to get started with CloudFront. To learn more about the best practices of building applications with CloudFront, visit AWS content delivery blogs.