Encryption and Decryption of API Payload on Kong API Gateway

Questions
1

Hi There,

I have successfully installed Kong API Gateway on my machine and also I have onboarded couple of services on the same. Currently, I have a requirement where I need to implement API encryption to the request/response payload using AES 256 encryption algorithm.

Basically, I want to expose my APIs in the encrypted version using AES 256 Algorithm. Following will be sample flow -

  1. Client application will be encrypting request body using AES 256 encryption algorithm and will send this encrypted payload in the API request body.
  2. Kong will receive this encrypted API request and will do the decryption of the same using AES 256 Algorithm. This decrypted body will be sent to upstream servers for processing.
  3. In the response flow, Kong will receive the plain text response body from upstream server. Then Kong will encrypt the response using same algorithm and will send it to the client application.

As I am new to Kong API Gateway, I need your assistance to understand how to implement this encryption on Kong API Gateway.

Thanks,
Nitiraj

2

This is usually handled between the client and the backend service provider. As an API Gateway (proxy) try to keep it minimal at the header level operations and not touching the payload as this can significantly impact your Gateway’s throughput and memory.

Also Kong does not have an OOB plugin to perform this, you can write a custom plugin to achieve this - but you should re-evaluate if that is really required.

3

Thanks @JohnWilliams for your reply.

We want to standardize request/responses for multiple service providers. That is where we need to modify the request and Response body.

And yes we were able to achive this using custom Go plugin and it is working fine.

I agree with your suggestion to avoid such changes at payload level but we are doing this for some APIs only. We will keep minimal changes at the Gateway level.

Thanks,
Nitiraj

4

@nitiraj_pachkale, could you clarify why you want to implement message-level protection on top of TLS (channel-level encryption)? Below listed can be few reasons.

  1. Does the client not want to rely solely on TLS level protection? Is there a risk of the TLS connection being terminated somewhere outside your control, where a third-party tool (like CloudCDN) could inspect your payload data?
  2. Do you have highly sensitive data that requires an additional layer of protection (payload encryption) on top of TLS? If feasible, you could consider MTLS, which would be as robust as enabling payload-level encryption.

If you must resolve the concerns listed above, below are possible solutions in increasing complexities and latency concerns that you can consider:

  1. End-to-end TLS with no termination at any intermediary system (third-party tools) between your client and server.
  2. Enhance the above by using MTLS.
  3. Encrypt and decrypt payloads at the message level, which seems to be your current direction.

Please check with your client and security team if solutions 1 or 2 are acceptable (#2 provides same level of protection). Additionally, consider the following concerns that need to be addressed if you decide to implement the payload encryption

  1. How will you securely share keys with your client and vice versa? You can’t share the plain text AES key as leaking that key will make your encrypted payload as same as it was a plain-text.
  2. Plain AES encryption is insufficient because sharing the plain AES secret key is insecure. Instead, use the concept of DEK (Data Encryption Key - ephemeral AES) to encrypt your data and then wrap the DEK with a CEK (Content Encryption Key - RSA). Standard JWE supports this mechanism: https://developer.visa.com/pages/encryption_guide/jwe-jws#section0.