1.0 Introduction
Fortanix Data Security Manager (DSM) uses Transport Layer Security (TLS) to secure communications between DSM and its clients. You can configure TLS settings for supported protocol versions, cipher suites, and key-exchange groups.
This article describes the TLS configuration options available in Fortanix DSM and explains how to configure and verify post-quantum hybrid key exchange for TLS 1.3 using X25519MLKEM768. This feature allows compatible clients to establish TLS 1.3 connections using a key exchange that combines classical and post-quantum cryptography.
NOTE
The post-quantum hybrid key-exchange configuration described in this guide is applicable only to Fortanix DSM on-premises deployments.
The client is the application or system connecting to DSM. For example, a browser, application, SDK client, or OpenSSL can act as the TLS client. The server is Fortanix DSM, which accepts the TLS connection.
2.0 TLS Configuration
TLS configuration controls how clients establish secure connections with Fortanix DSM.
The following TLS parameters can be configured:
TLS PARAMETER | DESCRIPTION |
|---|---|
Protocol version | The TLS protocol versions supported for client connections. |
Cipher suites | The cryptographic algorithms available for TLS connections. |
Key-exchange groups | The groups that can be used to establish shared keying material during the TLS handshake. |
Post-quantum key exchange | Configures the X25519MLKEM768 hybrid key-exchange group for TLS 1.3 connections. |
2.1 TLS Protocol Versions
Fortanix DSM supports TLS 1.2 and TLS 1.3 connections. TLS 1.3 provides support for the post-quantum hybrid key-exchange capability described in this guide.
The TLS protocol version is negotiated between the client and DSM during the TLS handshake.
2.2 TLS Cipher Suites
TLS cipher suites define the cryptographic algorithms used to protect application data exchanged over a TLS connection.
Examples: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384
Cipher suites and key-exchange groups are separate TLS configuration parameters. Selecting a cipher suite does not determine which key-exchange group is used.
For example, a TLS 1.3 connection can use:
Protocol: TLS 1.3
Cipher suite: TLS_AES_128_GCM_SHA256
Key-exchange group: X25519MLKEM768
2.3 TLS Key-Exchange Groups
A key-exchange group determines how the TLS client and server establish shared keying material during the handshake. Fortanix DSM supports classical key-exchange groups, such as X25519, secp256r1, secp384r1, and secp521r1, as well as hybrid groups that combine a classical key-exchange mechanism with a post-quantum mechanism.
Fortanix DSM supports key-exchange groups as part of its TLS configuration. The client advertises the groups it supports, and DSM selects a mutually supported group according to the server configuration and TLS negotiation.
2.4 Post-Quantum Hybrid Key Exchange
Fortanix DSM supports the following post-quantum hybrid key-exchange groups for TLS 1.3.
KEY EXCHANGE GROUP | CLASSICAL COMPONENT | POST-QUANTUM COMPONENT |
|---|---|---|
| X25519 | ML-KEM-768 |
| secp256r1 | ML-KEM-768 |
| secp384r1 | ML-KEM-1024 |
The hybrid approach is designed to provide protection against both classical and quantum cryptanalysis attacks against the TLS 1.3 protocol.
2.4.1 Client and Server Requirements
To negotiate X25519MLKEM768:
The connection must use TLS 1.3.
The TLS client must support X25519MLKEM768.
X25519MLKEM768 must be configured in the DSM server configuration.
The configured rollout must allow the key-exchange group to be selected.
3.0 Configure Post-Quantum Key Exchange
A Fortanix DSM system administrator can configure the TLS settings on a DSM cluster using the Cluster Administration API. The post-quantum hybrid key-exchange group is configured as part of the TLS 1.3 server configuration. The TLS 1.3 configuration contains separate settings for cipher suites and key-exchange groups.
3.1 API Endpoint
Use the following API endpoint:
PATCH /admin/v1/cluster?future=1Configure the TLS 1.3 key-exchange groups under the server TLS configuration.
The following example shows the structure of the TLS 1.3 configuration:
{
"tls_config_server": {
"tls_13": {
"cipher_suites": {
"TLS13_AES_256_GCM_SHA384": {},
"TLS13_AES_128_GCM_SHA256": {}
},
"key_exchange_groups": {
"KX_GROUP_X25519_MLKEM768": {
"handshakes_per_million": 1000
},
"KX_GROUP_SECP256R1": {},
"KX_GROUP_SECP384R1": {},
"KX_GROUP_SECP521R1": {},
"KX_GROUP_SECP256R1_MLKEM768": {
"handshakes_per_million": 1000
},
"KX_GROUP_SECP384R1_MLKEM1024": {
"handshakes_per_million": 1000
}
}
}
}
}The optional handshakes_per_million parameter controls the proportion of TLS handshakes for which the configured key-exchange group is eligible to be selected. For example, a value of 1000 allows the group to be selected for approximately 0.1% of handshakes. This enables gradual introduction of new key exchange groups into a live environment.
A cluster restart is required for the TLS configuration change to take effect.
4.0 Verify the TLS Configuration
After configuring X25519MLKEM768, use a TLS client that supports the key-exchange group to verify the negotiated connection.
4.2 Verify Using OpenSSL
Run the following command using OpenSSL version 3.5.0 or higher:
openssl s_client -connect <DSM_HOSTNAME>:443 -groups X25519MLKEM768Replace <DSM_HOSTNAME> with the hostname of your DSM cluster.
When X25519MLKEM768 is successfully negotiated, the output includes:
Negotiated TLS1.3 group: X25519MLKEM768The connection should also indicate TLS 1.3 and a TLS 1.3 cipher suite, for example:
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
WARNING
Depending on the value of the optional
handshakes_per_millionparameter, the server may not allow the specified key-exchange group for every handshake. If the value is less than 1,000,000, a client using the-groupsoption may need to make multiple connection attempts before the configured key-exchange group is selected.