FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Advanced

Is post-quantum key exchange supported? ​

Short answer

Yes, on the vService side with TLS 1.3. When Post-Quantum Key Exchange in the TLS Security Profile is turned on, TR7 offers the hybrid X25519MLKEM768 group; clients that support it connect with this group, and those that do not, with classic groups. The Core Engine of the vService must support ML-KEM; the v3.43 engines, including the default, support it. Only the key exchange is post-quantum; the certificates remain classic, and it is not applied to Backend Service connections.

How Does It Work? ​

  • When it is turned on, the vService offers the X25519MLKEM768 group as the first preference, together with classic groups. If Curve/ECDHE is selected in the profile, those curves remain as the classic fallback; if not, X25519 and P-256 do. The connection is never forced to post-quantum only.
  • Post-quantum key exchange is used only in TLS 1.3; if Max. SSL Version = TLSv1.2 in the profile, it has no effect.
  • If the selected Core Engine does not support ML-KEM, the setting is not applied, the vService continues to work with classic groups, and a notification starting with The selected core engine does not support is generated.

Enabling in TR7 ​

1
Adım 1 Open the profile form

The Configuration Menu is opened with the TR7 logo at the bottom left; on the Certificates & PKI → TLS Security Profiles screen, the profile used by the vService is selected and Edit is clicked; for a new profile, Add is clicked and Security Profile Name is entered.

2
Adım 2 Turn on post-quantum

In the Frontend-only Settings section, Post-Quantum Key Exchange is turned on (off by default). If Max. SSL Version is on, TLSv1.3 must be selected.

3
Adım 3 Save the profile

Edit at the bottom of the form is clicked (Add for a new profile).

4
Adım 4 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

5
Adım 5 Check the profile and the engine

In the Details panel, the SSL Security box under Frontend Settings is checked and the profile from step 3 is selected (profile selection on the vService). In the Core Engine field, it is checked that one of the v3.43 engines is selected.

6
Adım 6 Save

Save is clicked. In a cluster setup, with the default auto-sync, the change is also sent to the peer device; if Manual Sync Mode is on, it is sent to the peer device manually.

In WEB-CLI, the profile is updated; in place of <profile>, the profile is selected with Tab (lb ssl-security):

text
lb ssl-security update id <profile> --pqc true

Verification ​

  • With an OpenSSL 3.5 or later client: openssl s_client -connect 203.0.113.10:443 -servername www.example.com -groups X25519MLKEM768 -tls1_3 < /dev/null; X25519MLKEM768 is seen in the Negotiated TLS1.3 group line of the output.
  • In current Chrome or Firefox, the key exchange appears as X25519MLKEM768 in the Security panel of the developer tools.

Common Misconceptions ​

  • "The certificates also become post-quantum." Only the key exchange is post-quantum; the certificate signatures remain with classic algorithms.
  • "Old clients cannot connect." Since classic groups are offered as a fallback, old clients continue to connect.
  • "Backend Service connections are also protected." The setting is under Frontend-only Settings; it is applied only to the connection between the client and the vService.
  • "It works on all engines." It is applied only on engines that support ML-KEM (v3.43); on older engines, the setting has no effect.

How it is done in the documentation

Related questions