The Adaptive Proxy
Overview
The Adaptive Proxy is a tool for protecting communications between your applications and end-user devices from quantum attacks. It positions a proxy between your server and its clients, implementing quantum-safe encryption, decryption, and key encapsulation mechanisms. This ensures confidentiality, integrity, and authenticity of transmitted data. The Adaptive Proxy enables an application to have secure communication with clients regardless of their quantum-safe status.
The adaptive proxy enables seamless backward compatibility and interoperability by supporting both legacy and quantum-safe TLS clients. This allows for a smooth transition to quantum-safe cryptography without requiring changes to the application-side cryptographic standards. It enables the ability to protect traffic over the open internet using post-quantum cryptography (PQC), if the client supports it, while maintaining existing security protocols behind a protected network where legacy traffic protocols are in use for the rest of the system/applications.
An important application for the Adaptive Proxy is Internet of Things (IoT) devices. Due to their limited computing power and memory, IoT devices are particularly vulnerable to quantum attacks. You can use the Adaptive Proxy to allow secure and efficient communication with a diverse range of IoT devices, protecting your applications and network, without restricting the ability of these devices to connect to your services.
The Adaptive Proxy has the flexibility to shield applications from various client types such as legacy, QSC-enabled, and hybrid client applications. In hybrid environments, where old and modern technologies coexist, the Adaptive Proxy enables smooth communication between different types of clients and services.
It serves as a centralized point of control for managing communication protocols and security measures. This centralization simplifies configuration management, monitoring, and policy enforcement.
High level overview of the Adaptive Proxy
Transport layer security (TLS) termination
The Adaptive Proxy supports three types of TLS handling. The following table explains what happens in each case:
| Termination type | Description |
|---|---|
| Edge | The Adaptive Proxy terminates the SSL connection from the client and initiates a new SSL connection (or an HTTP connection), to forward to the backend servers. |
| Re-encrypt | The Adaptive Proxy decrypts the client request, then encrypts it again, using the respective backend server certificate and keys, when it forwards the request to the backend. |
| Passthrough | The Adaptive Proxy redirects the traffic at layer 4 without doing anything. The passthrough depends on the selected curve level; this can be configured in the proxy server base configuration. |
The Adaptive Proxy deployment patterns
The Adaptive Proxy offers three distinct deployment patterns, designed to provide seamless backward compatibility and interoperability for both legacy and quantum-safe TLS clients. These deployment models ensure secure communication while allowing enterprises to gradually transition towards quantum-safe cryptographic standards. One of the patterns is designed to be installed on a virtual machine, while the other two are tailored specifically for cluster environments such as Kubernetes or RedHat OpenShift (RHOS). The three Adaptive Proxy deployment patterns are described below:
Standalone virtual machine (VM)
-
Deployed on a standalone VM, this pattern is ideal for traditional infrastructure, handling secure communication without relying on containerized solutions.
Choose this option if you are not running your services in a cluster.
As ingress controller
-
In this configuration, the Adaptive Proxy replaces the default ingress controller of the Kubernetes or RHOS cluster, managing both traffic routing and TLS termination. It acts as the primary entry point for all external traffic, providing complete control
over the ingress, and ensuring seamless compatibility between legacy and modern quantum-safe clients.
This is the option you should choose if you are building a new cluster, or if replacing your existing ingress controller will not incur substantial infrastructure costs.
Post-ingress controller
-
Placed after the ingress controller in Kubernetes or RHOS, it focuses on TLS re-encryption and protocol translation, supporting both legacy and quantum-safe clients, while preserving existing routing functions.
Because it is installed alongside an existing ingress controller, it can be added to your cluster without any significant infrastructure costs.
The following table summarizes the network conditions that will guide your choice of installation type:
| Standalone VM | As ingress controller | Post-ingress | |
|---|---|---|---|
| Your existing proxy server is hosted on a virtual machine. | ✔ | ||
| The backend applications you want to protect are hosted on a virtual machine. | ✔ | ||
| You do not have a proxy server protecting the applications you host on your virtual machine. | ✔ | ||
| You currently use the out-of-the box ingress controller offered by your cloud service provider. | ✔ | ✔ | |
| You are planning to host new PQC enabled backend applications on an existing cluster. | ✔ | ||
| You are planning to enable PQC enabled/Hybrid clients to access your backend applications. | ✔ | ||
| You want to use your existing cluster to enable PQC backend application development, rather than provisioning a new cluster. | ✔ | ||
| You are not using a custom ingress controller for your cluster. | ✔ | ||
| You are building a new cluster with existing and newly developed applications. | ✔ | ||
| You want to migrate to PQC enabled TLS communication for all your applications in your existing cluster. | ✔ |