API Academy

Sponsored by Layer7

A padlock sitting on top of a keyboard.

API Gateway Cipher Suite Best Practices – Part 1

By Daniel GaudetPosted on

Following an API Gateway cipher suite best practices approach is critical to provide the highest level of security for API calls through your API gateways. As such, enabling secure HTTP isn’t enough these days. Organizations need to have a comprehensive plan when it comes to which cipher suite algorithms are used for their API gateways.

In this three part series, we’ll cover some of the best practices in selecting the best TLS cipher suite algorithms with your API gateways leveraging the latest recommendations from the NIST Information Technology Laboratory’s SP 800-52 Rev. 2 publication. In this first part, the focus is on the ingress (incoming) side of the API Gateway. The egress (outgoing) side will be the focus of part 2. In the final part, we will address scenarios where there’s some intermediary system like a load balancer or a web application firewall (WAF) between the client and the API gateway that performs TLS termination. As such, part one of this article assumes that the API gateway is performing the TLS termination for all client communication.

API Gateway Cipher Suite Best Practices: The Clean Slate Approach a.k.a TLS 1.3 everywhere

Let’s cover the easiest approach for selecting the best TLS cipher suite algorithm: Starting with a clean slate.

In this scenario, you have full control over all the clients that make API calls to the API gateway and they support making calls using TLS 1.3. Since all components involved support TLS 1.3, organizations should mandate that all API gateway instances/listeners explicitly support only TLS 1.3. This provides the best level of security. As for which cipher suite, NIST recommends that you only select a few from the list.

One of the major positive changes with TLS 1.3 is the reduction of the number of cipher suites available, from 22 down to 5. This makes selecting a cipher suite considerably easier. It’s also important to note that none of the cipher suites used in previous versions of TLS are available in TLS 1.3.

The following are the 5 cipher suites supported as part of TLS 1.3

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256
  • TLS_CHACHA20_POLY1305_SHA256

TLS 1.3 Cipher Suite Selection

As mentioned above, the recommendation is to pick a few algorithms out of the 3 in the list. From there, select the instance with the highest number of bits assuming all your clients support it. For example, if you were to select the AES Galois/Counter mode algorithm (GCM), you should select the one with 256 bits: TLS_AES_256_GCM_SHA384. This assumes all clients will support this algorithm and bit length. It is imperative that all clients support this cipher suite, otherwise the clients will not be able to make API calls to the API gateway. As part of regular security checks, API gateway listen ports should be probed to see if a valid API call can be made with non-approved cipher suites.

While this sounds like the approach that every organization should take, the reality is that in many cases, it won’t be possible for organizations to mandate TLS 1.3 for all API communication. The primary factor not all clients at this current state support TLS 1.3. While all the major browsers now support TLS 1.3 as do most mobile app SDKs, many clients do not.

Overtime, this will certainly change, but it’s nearly impossible to achieve full TLS 1.3 support across an organization and its customers. Instead, it might be possible to take this API Gateway Cipher Suite Best Practices for TLS 1.3 for a specific environment or new projects and use it as an initial step of phasing out support for older and less secure cipher suites and versions of TLS. In the next section, we’ll discuss what will be a more common scenario where there are clients that don’t support more secure cipher suites or newer TLS versions.

API Gateway Cipher Suite Best Practices: Legacy clients and TLS 1.0/TLS 1.1/TLS 1.2

So you have clients that don’t support TLS 1.3 (or TLS 1.2, or TLS 1.1) in your environment – your API gateways do support TLS 1.3, right? It could be internal clients, or possibly customers accessing your APIs through web apps with older versions of web browsers that don’t support TLS 1.3. Maybe there are IoT devices that have not had any updates to support the latest standards either due to outdated libraries, or lack of hardware support. It might be legacy systems that make API calls that have been running for years without a hitch and there are no plans to update them. As such, organizations need to have a plan to deal with this reality. It is important to know what the highest common denominator is when it comes to the client support for TLS version and cipher suites.

Best practices for older TLS versions

The latest NIST recommendation is to drop TLS 1.0 and TLS 1.1 as soon as possible since they are deemed to not be at the level required to provide proper protection for network communication. As for cipher suites, they recommend that the use of cipher suites that use the Triple Data Encryption Algorithm (3DES) should no longer be used due to the limited amounts of data that can be processed under a single key. Also, only cipher suites which have a valid certificate containing a signature providing at least 112 bits of security should be used. In many cases, clients that support TLS 1.1 and TLS 1.2 should be able to leverage more secure cipher suites.

NIST provides 3 points to guide the selection for cipher suites for TLS 1.0, 1.1, and 1.2:

1. Prefer ephemeral keys over static keys (i.e., prefer DHE over DH, and prefer ECDHE over ECDH). Ephemeral keys provide perfect forward secrecy.

2. Prefer GCM or CCM modes over CBC mode. The use of an authenticated encryption
mode prevents several attacks. Note that these are not available in versions prior to TLS 1.2.

3. Prefer CCM over CCM_8. The latter contains a shorter authentication tag, which
provides a lower authentication strength.

SP 800-52 Rev. 2 Section 3.3.1.1 Cipher Suites for TLS 1.2 and Earlier Versions

Ideally, organizations should try to follow these recommendations while also trying to go with the highest bit length supported with their clients. Also, the recommendation of only selecting a few cipher suites is still in effect for older TLS versions. When dealing with a multitude of different types of clients, it’s not always possible to follow the recommendations and additional measures should be taken.

Segmented API Gateway Deployment

In environments where there’s a segmented API gateway deployment where there are domain specific deployments, it is recommended to break up each domain with it’s own set of guidelines. The organization will need to assess the clients capabilities for each domain.

This assessment would include the highest TLS versions and the cipher suites supported, and the endpoints that are called for each client type. Each client needs to be assessed following the above recommendations. The outcome will be a list of the recommended cipher suites and TLS versions for each client.

The above approach is taken for each domain and as such, the highest cipher suites and TLS versions can be applied. While it can take more effort to have different standards for each domain, this will minimize the “rotten apple” scenario. This is where a single rotten apple, in this case clients that can only support less secure cipher suites and TLS versions, impacts all apples a.k.a. endpoints.

In cases where there are perimeter API gateways that serve multiple or all endpoints, this approach might not work since you have to handle the lowest common denominator of clients.

API gateways with multiple endpoints

If you have API gateways with multiple endpoints serving multiple clients, a few approaches can be taken to minimize the rotten apple scenario.

If a handful of endpoints have clients that are less secure, we recommend that those endpoints be segregated to a different API gateway or a different listen port. This will minimize the risk exposure of having broad support for less secure cipher suites and TLS versions for all endpoints. We’ll discuss a bit further the need to perform this assessment on a regular basis with the goal to remove support for less secure cipher suites and TLS versions.

If most or all API endpoints have a broad range of clients including those that require less secure cipher suites, then an organization will need to make a compromise to support these less secure cipher suites and TLS versions. There’s a mechanism available on certain API gateways to help minimize the impact of allowing the use of less secure cipher suites: Server-side Cipher Suite Priority. There will still be a risk related to older TLS versions, but this will still help mitigate some of the risk. But before we go there, we’ll have a high-level overview of the TLS handshake which will help us better understand the solution.

TLS Handshake

At this point, it’s important to have a short overview of how clients initiate a TLS connection with an API Gateway. During the TLS handshake, the client sends a message to the API gateway with a list of cipher suites it will accept. The API gateway chooses from the list and sends a handshake message back indicating which cipher suite it will accept. While the client may order the list with what it considers to be the strongest cipher suites listed first, the server may ignore the preference order and choose any of the cipher suites proposed by the client. The server may have its own cipher suite preference order, and it may be different from the client’s preference.

As mentioned earlier, if no cipher suites are common to the client and API gateway, the connection is aborted. It should be noted that not all API gateways support this server-side cipher suite priority capability.

Server-side Cipher Suite Priority

Why the need for server-side cipher suite priority? Imagine if you need to support most of the cipher suites to support your client base which include some that are less secure, especially with older clients. If you don’t specify a preference order and instead rely on external clients or closed 3rd party systems to determine which cipher suite to use could result in less secure cipher suites being used, even with newer clients. By specifying the order, an organization can enforce its own rules as to which cipher suites should be used in which order.

As part of following an API gateway cipher suite best practices approach, organizations should put some importance to have API gateways on having the capability to specify the order of precedence for cipher suites. Otherwise, they risk having situations where less secure cipher suites are used. In all cases, organizations should enable server-side cipher suite priority.

Leveraging server-side cipher suite priority should be used in all cases. This allows organizations to determine what is the best cipher suites used for them and not let clients determine the cipher suites used.

Regular Assessment of Clients

While it’s understood that supporting less secure cipher suites and TLS versions is something that organizations need to do, regular assessments of clients should be performed to be able to remove less secure cipher suites as the client-base changes over time. It’s not uncommon that organizations update their cipher suites with new deployments, but not touch older deployments and allow these systems to still use older and less secure cipher suites. This should be considered a high-risk scenario. Instead, organizations should assess all clients at regular intervals to minimize any potential risk for having unnecessary ciphers enabled.

The goal would be to reduce and eliminate the use of insecure cipher suites and TLS versions on API gateways with a goal to eventually only support TLS 1.3.

Conclusion – API Gateway Cipher Suite Best Practices for Egress Communication

As we finish part 1, here’s a summary of what we covered:

  • The goal is for organizations to use TLS 1.3 throughout over time
  • Most cases will require the support of TLS 1.2 and older versions including less secure cipher suites.
  • Compromises will need to be made to support older clients, but leveraging server-side cipher suite priority can help mitigate some of the risk.
  • Regular assessments of clients should be done with the intention of reducing and eliminating the use of insecure cipher suites and older TLS versions on API gateways.

In part two, we’ll take a look at the egress communication of an API gateway as it relates to API Gateway Cipher Suite Best Practices.

Note: We’ve referenced the NIST Information Technology Laboratory’s SP 800-52 Rev. 2 publication and we advise that you review it to gather additional insights as it relates to implementing and supporting TLS in your organization. It goes in a lot more details to specific NIST-approved ciphers both present and past and can be applied to broader uses outside the use of API gateways. It doesn’t cover all use cases for all organizations since it’s specific to cases as it relates to the US government, but it can be a great learning resource for anyone wanting to know more about the topic.