Skip to content

Limit allowed elliptic curves to X25519MLKEM768 #802

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
Miciah wants to merge 1 commit into
base: master
Choose a base branch
from
+1 −5
Draft

Limit allowed elliptic curves to X25519MLKEM768 #802

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 1 addition & 5 deletions images/router/haproxy/conf/haproxy-config.template
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,11 +131,7 @@ global
{{- end }}
{{- end }}

# By default when a ROUTER_CURVES is not defined HAProxy
# will use its built-in default supported groups for TLS key exchange.
{{- with (env "ROUTER_CURVES") }}
ssl-default-bind-curves {{ . }}
{{- end }}
ssl-default-bind-curves X25519MLKEM768

@coderabbitai coderabbitai Bot Jun 24, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find the HAProxy/OpenSSL versions and any existing references to the curve/ROUTER_CURVES.
fd -t f 'Dockerfile' images/router | xargs -r rg -nP 'haproxy|openssl' -i

# Look for the HAProxy version pinned for the router image.
rg -nP -i 'haproxy[-_ ]?(version|ver|=)' --glob '!**/vendor/**' -C2

# Confirm whether ROUTER_CURVES is still referenced/documented elsewhere (docs, e2e, defaults).
rg -nP '\bROUTER_CURVES\b' -C2

Repository: openshift/router

Length of output: 4301

🌐 Web query:

HAProxy ssl-default-bind-curves X25519MLKEM768 OpenSSL minimum version support

💡 Result:

To use X25519MLKEM768 in HAProxy configuration directives such as ssl-default-bind-curves, your HAProxy instance must be linked against OpenSSL 3.5 or newer [1][2][3]. Support for X25519MLKEM768 (a hybrid post-quantum key exchange mechanism) was introduced in OpenSSL 3.5 [4][5]. Because HAProxy relies on the underlying OpenSSL library for TLS handshake capabilities, it cannot negotiate this group if the linked library is older [2][3]. Key considerations for this configuration: 1. Minimum Version: You must be using OpenSSL 3.5+ [1]. You can verify the OpenSSL version linked to your HAProxy instance by running the command: haproxy -vv [1][6]. 2. Configuration Directive: You can configure the allowed curves using the ssl-default-bind-curves directive in the global section of your HAProxy configuration [1][2]: global ssl-default-bind-curves X25519MLKEM768:X25519:secp256r1:secp384r1 3. Backend Support: If you also need PQC for the backend (origin server) side, you must ensure you are using HAProxy 2.9 or later to utilize the ssl-default-server-curves directive [1]. 4. Potential Issues: The X25519MLKEM768 key exchange produces significantly larger TLS Client Hello messages than classical curves [4]. In some environments, this may exceed the Maximum Transmission Unit (MTU) of a single TCP segment, potentially causing handshake failures or timeouts when middleboxes or firewalls drop the fragmented packets [4]. If such issues occur, it is often recommended to ensure the curve is supported but perhaps not the sole priority in your curve list [4].

Citations:

🏁 Script executed:

# Check for OpenSSL version references in the codebase and Dockerfiles
rg -i 'openssl' --glob='images/router/**' -C 2

# Verify the full scope of ROUTER_CURVES removal
rg '\bROUTER_CURVES\b' -C 3

# Check for OpenSSL version in base images and dependencies
fd -t f 'Dockerfile*' | xargs rg -l 'FROM' | head -5 | xargs -I {} sh -c 'echo "=== {} ===" && head -5 {}'

# Look for environment variable documentation or defaults
rg -i 'ROUTER.*CURVE' --glob='**/*.{md,txt,sh,yaml,yml}' -C 2

Repository: openshift/router

Length of output: 351

🌐 Web query:

haproxy28 package OpenSSL version RHEL dependency

💡 Result:

The haproxy28 package is a version-specific distribution of HAProxy (version 2.8) commonly found in Red Hat Enterprise Linux (RHEL) 9 environments [1][2][3]. Regarding OpenSSL, the HAProxy RPM packages on RHEL, including those for version 2.8, do not have a hardcoded or exclusive dependency on a specific minor version of OpenSSL [4][5]. Instead, they are built against the OpenSSL development headers available on the system at build time (e.g., openssl-devel) [4][6][7]. Consequently: 1. Dynamic Linking: HAProxy dynamically links against the version of the OpenSSL library (libssl/libcrypto) provided by the host operating system [8][5]. On RHEL 9, this is typically OpenSSL 3.0 [4][9]. 2. Build Requirements: The package specification files (spec files) for HAProxy on RHEL explicitly list openssl-devel as a BuildRequire [4][6][7]. This ensures that when the package is compiled for the distribution, it is built against the OpenSSL version supported by that specific RHEL release [4][7]. 3. Runtime Behavior: Because it relies on the system's OpenSSL, HAProxy's TLS capabilities (such as ALPN support, protocol versions, and FIPS compliance) are dictated by the underlying system's OpenSSL configuration and capabilities [10][11][5]. If you are using the haproxy28 package on RHEL 9, it will utilize the system-provided OpenSSL 3.0 library by default [4][9]. Users requiring different OpenSSL behavior often manage this via system-wide crypto policies or by building custom HAProxy versions, as standard RHEL RPMs are designed to maintain compatibility with the platform's native libraries [9][5].

Citations:

🏁 Script executed:

# Check the base image to understand the OpenSSL version
cat images/router/haproxy/Dockerfile.ocp | head -20

# Search more carefully for ROUTER_CURVES in all file types
fd . --type f | xargs rg 'ROUTER_CURVES' 2>/dev/null | head -20

# Check if there's any mention of OpenSSL 3.5 or PQC in the PR context
rg -i '(openssl 3\.5|pqc|post-quantum|ml-kem)' --type-list | head -20

# Look at the actual template change context to see what was removed
sed -n '130,140p' images/router/haproxy/conf/haproxy-config.template

Repository: openshift/router

Length of output: 1973

🌐 Web query:

RHEL 9 OpenSSL 3.5 availability support haproxy X25519MLKEM768

💡 Result:

Red Hat Enterprise Linux (RHEL) 9 currently ships with OpenSSL 3.0.x, not OpenSSL 3.5 [1][2][3]. OpenSSL 3.5 is an independent upstream release made available on April 8, 2025 [4][5]. Because RHEL 9 is committed to a stable ABI and API for its provided OpenSSL 3.0 version [2], OpenSSL 3.5 is not natively available as a standard system package in RHEL 9. Regarding HAProxy and X25519MLKEM768 (also known as Kyber768): 1. Availability: Support for X25519MLKEM768 in the TLS handshake is provided by the underlying SSL library [6]. Since RHEL 9's native OpenSSL 3.0 does not include this PQC (Post-Quantum Cryptography) algorithm, you cannot use it via the standard RHEL-provided HAProxy packages without additional configuration or custom builds [7]. 2. Implementation: Users who require X25519MLKEM768 support with HAProxy typically achieve this by: - Using a custom-built HAProxy linked against a newer version of OpenSSL (e.g., 3.5+) or by integrating the Open Quantum Safe (OQS) provider if the library supports it [6][7][8]. - Configuring HAProxy's ssl-default-bind-curves (for frontends) and ssl-default-server-curves (for backends) to include X25519MLKEM768 [7][8]. 3. Known Issues: Enabling X25519MLKEM768 can lead to handshake failures in specific HAProxy configurations, particularly when using req.ssl_sni without adequate tcp-request inspect-delay settings [9]. This is because the larger TLS Client Hello packets associated with PQC algorithms may exceed the default buffer or timing windows expected by older HAProxy configurations [9][7]. If you must implement this, ensure your configuration allows sufficient time for the TLS handshake to complete [9].

Citations:

Do not merge this config to production — X25519MLKEM768 will cause HAProxy to fail at startup on RHEL 9.

Hardcoding ssl-default-bind-curves to just X25519MLKEM768 creates a critical failure mode:

Config-load failure (router outage): X25519MLKEM768 requires OpenSSL 3.5+, but the router image uses RHEL 9, which ships with OpenSSL 3.0. When HAProxy starts, it will reject the unknown curve name and fail to load the configuration, taking down the router entirely. The haproxy28 package on RHEL 9 dynamically links against the system's OpenSSL 3.0, which does not implement this post-quantum group.

Removing the ROUTER_CURVES lookup also strips operator/admin tuning capability. Per the PR description, this is an intentional draft-only change for collecting ML‑KEM perf data — it must not merge to a release branch as-is.

If this is intended for testing on a custom-built OpenSSL 3.5 or OQS-enabled environment, that constraint must be documented clearly (e.g., in a README or build note) so it is never accidentally deployed against standard RHEL 9 systems.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@images/router/haproxy/conf/haproxy-config.template` at line 134, The
hardcoded ssl-default-bind-curves directive set to X25519MLKEM768 will cause
HAProxy startup failure on RHEL 9 systems that use OpenSSL 3.0, which does not
support this curve. Revert the ssl-default-bind-curves line from the hardcoded
X25519MLKEM768 value back to using the dynamic ROUTER_CURVES variable or
template substitution (likely something like ${ROUTER_CURVES} or similar
placeholder). This restores operator configuration capability and ensures the
config loads successfully on standard RHEL 9 deployments. If testing
post-quantum curves is needed, clearly document in a README or build note that
it requires a custom OpenSSL 3.5+ environment to prevent accidental production
deployment.


defaults
{{- with $value := env "ROUTER_MAX_CONNECTIONS" "50000" }}
Expand Down