How can you protect against a man-in-the-middle forging a TLS Client Hello that offers insecure algorithms?
According to PAN-OS documentation for "Traceability and Control of Post-Quantum Cryptography",
Traffic encrypted by PQC [post-quantum computing] or hybrid PQC algorithms cannot be decrypted yet, making these algorithms vulnerable to misuse.
The implicit statement here is that non-PQC algorithms can all be decrypted now, which is awkward to say the least. But my question is in their implementation,
If SSL traffic matches an SSL Forward Proxy or SSL Inbound Inspection Decryption policy rule, the firewall prevents negotiation with PQC, hybrid PQC, and other unsupported algorithms. Specifically, the firewall removes these algorithms from the ClientHello, forcing the client to negotiate with classical algorithms. (For a list of supported cipher suites, see PAN-OS 11.1 Decryption Cipher Suites.) This enables continuous decryption and threat identification through deep packet inspection. If the client strictly negotiates PQC or hybrid PQC algorithms, the firewall drops the session. In the Decryption log for the dropped session, the error message states that the "client only supports post-quantum algorithms.” To see details of successful or unsuccessful TLS handshakes in the Decryption logs, enable both options in your Decryption policy rules.
Is it possible to use a PQC or hybrid-PQC by renegotiating the connection without a plaintext Client Hello? Client Hello is documented in RFC8446. Is there anyway to protect against PAN-OS making TLS 1.3 less secure?
