Limit allowed elliptic curves to X25519MLKEM768#802
Conversation
Hard-code the list of allowed elliptic curves to just X25519MLKEM768. This commit is for testing purposes only, namely to collect data on the performance impact of ML-KEM. * images/router/haproxy/conf/haproxy-config.template: Hard-code ssl-default-bind-curves to X25519MLKEM768.
|
/test perfscale-aws-ingress-perf |
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
WalkthroughThe HAProxy config template removes the conditional ChangesHAProxy TLS Curves Configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with 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.
Inline comments:
In `@images/router/haproxy/conf/haproxy-config.template`:
- 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.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: b9c665ae-cda7-4bd6-a0f9-927483073038
📒 Files selected for processing (1)
images/router/haproxy/conf/haproxy-config.template
| {{- with (env "ROUTER_CURVES") }} | ||
| ssl-default-bind-curves {{ . }} | ||
| {{- end }} | ||
| ssl-default-bind-curves X25519MLKEM768 |
There was a problem hiding this comment.
🩺 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' -C2Repository: 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:
- 1: https://pqprobe.com/blog/haproxy-quantum-ready?lang=en
- 2: NE-2333: Add support for configurable SSL curves in HAProxy configuration #678
- 3: Post-Quantum Cryptography (PQC) Support haproxy/haproxy#3171
- 4: https://docs.openssl.org/3.5/man3/SSL_CTX_set1_curves/
- 5: https://docs.openssl.org/master/man7/EVP_PKEY-MLX-KEM/
- 6: https://docs.haproxy.org/3.0/configuration.html
🏁 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 2Repository: 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:
- 1: https://access.redhat.com/errata/RHBA-2025:20686
- 2: https://www.rpmfind.net/linux/RPM/centos-stream/9/appstream/x86_64/haproxy-2.8.14-1.el9.x86_64.html
- 3: NE-1444: egress/dns-proxy: switch to haproxy28 RPM package images#160
- 4: https://gitlab.com/redhat/centos-stream/rpms/haproxy/-/raw/c9s/haproxy.spec
- 5: https://www.haproxy.com/blog/become-fips-compliant-with-haproxy-enterprise-on-red-hat-enterprise-linux-8
- 6: https://gitlab.com/redhat/centos-stream/rpms/haproxy/-/raw/c8s/haproxy.spec
- 7: https://gitlab.com/redhat/centos-stream/rpms/haproxy/-/raw/c10s/haproxy.spec
- 8: https://github.com/haproxy/haproxy/blob/master/INSTALL
- 9: https://discourse.haproxy.org/t/compile-haproxy-with-a-different-version-of-openssl/9124
- 10: https://bugzilla.redhat.com/show_bug.cgi?id=1595865
- 11: https://access.redhat.com/errata/RHSA-2019:1436
🏁 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.templateRepository: 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:
- 1: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/9.0_release_notes/index
- 2: https://www.redhat.com/en/blog/experience-bringing-openssl-30-rhel-and-fedora
- 3: https://access.redhat.com/errata/RHSA-2024:6783
- 4: https://openssl-library.org/post/2025-04-08-openssl-35-final-release/
- 5: https://github.com/openssl/openssl/releases/tag/openssl-3.5.0
- 6: Post-Quantum Cryptography (PQC) Support haproxy/haproxy#3171
- 7: https://pqprobe.com/blog/haproxy-quantum-ready?lang=en
- 8: https://brunohenc.from.hr/using-kyber-ml-kem-with-haproxy.html
- 9: req.ssl_sni: TCP Abort after TLS "Client Hello" with X25519MLKEM768 haproxy/haproxy#3148
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.
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
# Try to fetch finished.json and build-log.txt from the GCS bucket
BASE="https://storage.googleapis.com/test-platform-results/pr-logs/pull/openshift_router/802/pull-ci-openshift-router-master-perfscale-aws-ingress-perf/2069571831462891520"
echo "=== finished.json ==="
curl -sf "${BASE}/finished.json" || echo "FAILED to fetch finished.json"
echo ""
echo "=== started.json ==="
curl -sf "${BASE}/started.json" || echo "FAILED to fetch started.json"
echo ""
echo "=== build-log.txt (last 200 lines) ==="
curl -sf "${BASE}/build-log.txt" | tail -200 || echo "FAILED to fetch build-log.txt"Length of output: 25736
Root Cause:
|
| Stage | Status |
|---|---|
src build |
✅ Succeeded (2m20s) |
haproxy-router-base build |
✅ Succeeded (3m36s) |
haproxy-router build |
✅ Succeeded (4m18s) |
Cluster install (ipi-install-install) |
✅ Succeeded (54m42s) |
openshift-qe-workers-infra-workload |
❌ Failed — ImagePullBackOff for 1h, then timed out |
At job startup, the CI system imported ci/ocp-qe-perfscale-ci:latest into the pipeline as pipeline:ci-ocp-qe-perfscale-ci-latest. However, the workload step's pod spec referenced a different tag (ci-XXXXXX-perfscale-ci-latest) that was never created in the pipeline registry, causing the manifest unknown error. The multiarch-tuning-operator also hit the same missing manifest when trying to determine architecture support.
Conclusion
This is a CI infrastructure / test configuration issue — likely a mismatch or resolution bug in the openshift-qe-workers-infra-workload step definition's image reference, not caused by anything in this PR. The PR's code changes (HAProxy template) were successfully built and the cluster was installed cleanly. You may want to re-trigger the test (/test perfscale-aws-ingress-perf) to see if it's a transient issue, or file a bug against the openshift-qe-perfscale-ci step if it reproduces.
|
/test perfscale-aws-ingress-perf |
|
@Miciah: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
1 participant
Hard-code the list of allowed elliptic curves to just X25519MLKEM768.
This PR is for testing purposes only, namely to collect data on the performance impact of ML-KEM.
images/router/haproxy/conf/haproxy-config.template: Hard-codessl-default-bind-curvestoX25519MLKEM768.Summary by CodeRabbit
X25519MLKEM768for improved security and consistency. The setting is now applied by default rather than relying on environment variable configuration.