Quantum cryptography and your TLS inspection
Sep 12th, 2024 by Jesper Kråkhede
In August NIST published the first three standards for post-quantum cryptography: ML-KEM for key exchange and ML-DSA and SLH-DSA for signatures. They are designed to resist attacks from future quantum computers, which could break the RSA and elliptic curve cryptography we use today.
Why now, when no such quantum computer exists? Because of ‘harvest now, decrypt later’. An attacker can record encrypted traffic today and decrypt it in ten or fifteen years. If your data needs to stay secret that long, you are already late.
The browsers have already started. In April, Chrome enabled a hybrid post-quantum key exchange by default. And something interesting happened. Some networks stopped working. The new key exchange makes the first message in the TLS handshake much bigger, and some firewalls and TLS inspection appliances couldn´t handle it. Connections were dropped or hung.
That is a preview of what is coming for TLS inspection. Middleboxes that decrypt and re-encrypt traffic will need to support the new algorithms on both sides, or they will either break connections or force them down to weaker cryptography. And the new algorithms use bigger keys and more computing power, which affects the capacity of every appliance that does inspection.
What to do now? Inventory where you use cryptography, including your inspection appliances. Ask your vendors for their post-quantum roadmap. Test with the new algorithms enabled. And ask yourself which traffic you really need to inspect, and where endpoint and identity signals can do the job instead. This will also affect your costs to the positive side so crack on!
The quantum computer isn´t here yet. The migration already is.