Why, Where and How of PQC Cipher Translation Proxy

[JayGolf]

This blog was written by Saad Khan, Sr. Technical Marketing Engineer

Why is the translation of ciphers to be "quantum-safe" a necessity?

The cybersecurity landscape is rapidly evolving, driven by the looming threat of cryptographically relevant quantum computers (CRQCs) . When fully realized, these machines will have the capability to break the public/private key encryption algorithms that secure our digital way of life. As part of our commitment to ensuring future-proof security, Palo Alto Networks is excited to introduce a groundbreaking feature in our next-generation firewalls (NGFWs) running PAN-OS 12.1 Orion: Quantum-Safe Cipher Translation.

This new functionality allows organizations to begin the critical transition to post-quantum cryptography (PQC) immediately, without disrupting existing infrastructure or waiting for a complete industry-wide PQC overhaul. Industry experts expect that this transition will take many years requiring significant updates to devices, applications and infrastructure. 

This will especially be challenging for the 100s and 1000s of private applications that use a variety of underlying cryptography libraries. Often application developers don’t know which crypto modules are in use, which cipher algorithms are negotiated or how they are configured. 

What is Quantum-Safe Cipher Translation?

The Quantum-Safe Cipher Translation feature in PAN-OS 12.1 Orion tackles the challenge of migrating TLS communications to a quantum-safe standard.

The core of this feature is the hybrid key exchange mechanism. This mechanism enables the translation of a TLS classical cipher suite into a quantum-safe equivalent or vice-versa. This translation is performed seamlessly on the firewall, ensuring that the traffic flowing through your network is secured with both a classical (e.g., ECDHE) and a quantum-safe (PQC) key exchange algorithm simultaneously. 

The Quantum-Safe Cipher Translation feature provides flexibility in selecting post-quantum key exchange mechanisms (KEMs) based on your organization's risk tolerance and standardization requirements. See documentation for the list of cipher suites supported in PAN-OS 12.1

The firewall allows you to configure and use the following Key Exchange Algorithms:

PQC Standard	Key Exchange Algorithm	Description
PQC-Standard	ML-KEM	NIST standardized algorithm for Key Encapsulation Mechanism (KEM). Recommended for immediate adoption.
PQC-Experimental	HQC	Classic McEliece variant, often considered for long-term security.
PQC-Experimental	BIKE	QC-MDPC code-based algorithm, designed for high performance.
PQC-Experimental	Frodo-KEM	Lattice-based key encapsulation mechanism, known for its conservative security model.

By separating these algorithms into 'Standard' and 'Experimental' categories within the Decryption Profile settings, PAN-OS provides a clear path for organizations to adopt NIST-standardized PQC while also allowing for testing and readiness with emerging alternatives, if necessary.

Key Benefits

• Immediate Quantum Readiness: Secure your communications against the "Harvest Now, Decrypt Later" threat model.
• Zero Disruption: The feature operates by translating existing classical ciphers; no changes are required on the client or server side to enable PQC protection.
• Resilience: By using a hybrid approach, the security of the communication relies on the stronger of the two key exchange mechanisms (classical or PQC), providing robust security even if one is compromised.

How the Hybrid Key Exchange Works

The Quantum-Safe Cipher Translation is implemented through a hybrid key exchange process. This process combines a traditional, well-vetted classical algorithm with a new, quantum-safe algorithm.

Here is a simplified workflow:

1. Classical Negotiation: The client and server negotiate a standard classical TLS cipher suite.
2. PAN-OS Intervention: The PAN-OS 12.1 Orion firewall intercepts the communication via SSL Forward proxy or SSL Inbound Inspection. Based on configured policies and decryption profiles,  it injects the necessary PQC-based key material into the TLS handshake process to client-side, server-side or both sessions, depending on the configuration. 
3. Key Establishment: The final session key is derived from a combination of the classical key exchange and the quantum-safe key exchange.
4. Secure Communication: The resulting TLS session is secured with a hybrid key, providing defense against both classical and quantum attacks.

Getting Started with Quantum-Safe Cipher Translation

To begin leveraging this critical new security feature, follow these general steps:

1. Upgrade to the latest PAN-OS Orion 12.1.2 or higher.
   
   Note: PQC-Standard and PQC-Experimental are only supported from Protocol version TLS 1.3, at a minimum Protocol Versions Max Version should be configured with TLS 1.3. 

1. Within the Web UI: Objects → Decryption profile, in the SSL Protocol Settings → Key Exchange mechanism section, you can now enable PQC-Standard and PQC-Experimental.
   
   
2. Additionally, the Preferred Session Settings gives you granular control over which side of a proxied session is allowed to use Post-Quantum Cryptography (PQC) Key Encapsulation Mechanisms (KEMs).
   
   Note: If a client or server doesn't support PQC, the firewall attempts to negotiate an existing cipher supported by these endpoints as a fallback mechanism.
    
1. Post-Quantum SSL preferred for Client-side session—The firewall (acting as server) negotiates PQC algorithms if included in client's cipher suite list.
2. Post-Quantum SSL preferred for Server-side session—The firewall (acting as client) places PQC algorithms first in its cipher suite list.
3. Additionally, the Preferred Session Settings gives you granular control over which side of a proxied session is allowed to use Post-Quantum Cryptography (PQC) Key Encapsulation Mechanisms (KEMs).
   
   Note: If a client or server doesn't support PQC, the firewall attempts to negotiate an existing cipher supported by these endpoints as a fallback mechanism.
   

4. Once you have created the decryption profile object, it can be applied to the decryption policy under  Policies → Decryption.This  Profile can be applied to both SSL Inbound Inspection and SSL Forward Proxy.

Use Cases

Inbound Inspection Protecting Applications

When securing internally hosted applications accessed by external clients the SSL Inbound Inspection use case is ideal. This is often the first step for organizations with modern clients (e.g., Google Chrome, Microsoft Edge, and Prisma Browser) that support Hybrid Key Exchange mechanisms (like X25519MLKEM768).

How it works:

1. Proxy Setup: The firewall acts as a man-in-the-middle proxy, terminating the client's connection and initiating a new connection to the destination server. Two separate TLS sessions are established:
   • Client <-> Firewall (Session 1)
   • Firewall <-> Server (Session 2)
2. PQC Application:
   • Client-Side (Session 1): The firewall negotiates a quantum-safe hybrid key exchange (e.g., X25519MLKEM768) with the client, securing the connection against 'Harvest Now, Decrypt Later' attacks.
   • Server-Side (Session 2): The firewall maintains a classical cipher connection with the hosted server, which may not yet support PQC.
     
3. Configuration:
   • Import the application's server certificate onto the firewall.
   • In the Decryption Profile, enable PQC-Standard.
   • Under Preferred Session Settings, enable PQC Key Exchange for the Client-side session, see example below
     

  

• Once the Decryption profile is created, apply it to the decryption policy, along with the Certificate.  

This approach provides immediate PQC security to external clients without requiring any changes or upgrades to the back-end application servers.

SSL Forward Proxy for Protecting Critical Infrastructure 

For securing outbound traffic from internal users, OT/IoT or any application connections to external resources, the SSL Forward Proxy use case is essential, particularly when you cannot import the destination server's certificate onto the firewall.

How it works:

1. Proxy Setup: The firewall intercepts the client's outbound TLS connection, acting as a man-in-the-middle proxy. It terminates the client-side session and initiates a new server-side session to the destination.
   • Client <--> Firewall (Session 1)
   • Firewall <--> Server (Session 2)
2. Certificate Handling: Since the firewall does not possess the server's private key, it performs certificate impersonation. It uses an organization’s Enterprise CA certificate or a locally self-signed CA certificate (configured on the firewall) to sign an impersonation certificate on behalf of the destination server and presents this to the client.
3. TLS Handshake Interception:
   • When the client establishes a TLS handshake, the firewall intercepts it, acting as the server.
   • The firewall then establishes a separate session to the destination server.
   • When the server returns its Server Certificate in its ServerHello, the firewall analyzes the legitimate certificate, signs it with the configured Enterprise/local CA, and presents the newly signed certificate to the client.
4. PQC Application: In the forward proxy mode, if either the client or the destination server supports PQC KEMs, the firewall will negotiate and utilize the quantum-safe key exchange on the respective session(s).
   
5. Configuration:
   • Ensure the firewall is configured with an Enterprise CA or locally self-signed CA for signing certificates.
   • In the Decryption Profile, enable PQC-Standard (and/or PQC-Experimental).
   • Under Preferred Session Settings, PQC Key Exchange can be enabled for the Client-side session, the Server-side session, or Both.
     

This method ensures that outbound traffic is secured with PQC protection, providing resilience for your critical infrastructure without requiring PQC support from internal client machines or external servers.

Conclusion

Palo Alto Networks NGFWs significantly ease the transition to a quantum-safe world, which can otherwise be a multi-year, resource-intensive endeavor. The Quantum-Safe Cipher Translation feature simplifies this process by enabling quantum-safe compliance through a no-code-change translation of traffic, potentially saving customers millions of dollars in effort and protecting them against attackers.