fix(io): validate server TLS FIPS compliance#1954
Conversation
Binary Size Analysis (Agent Data Plane)Baseline: 6860990 · Comparison: 0bef301 · diff ✅ Binary size difference within thresholdChanges by Module
Detailed Symbol Changes |
Regression Detector (Agent Data Plane)Run ID: Optimization Goals: ✅ No significant changes detectedFine details of change detection per experiment (5)Experiments configured
Bounds Checks: ✅ Passed (5)
ExplanationA change is flagged as a regression when |Δ mean %| > 5.00% in the regressing direction for its optimization goal AND SMP marks the experiment as a regression ( |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e18650bbc9
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if !config.fips() { | ||
| return Err(generic_error!("Server TLS configuration is not FIPS compliant.")); |
There was a problem hiding this comment.
Reject server key logging in FIPS validation
In FIPS builds, this accepts any ServerConfig whose rustls FIPS marker is true, but rustls 0.23.41's ServerConfig::fips() does not inspect operational secret-export settings such as key_log. A caller can pass a config with config.key_log replaced through HttpServer::with_tls_config/API with_tls_config, this check passes, and the server will export TLS secrets even though this crate already treats TLS key logging as non-FIPS-compliant on the client side. The server validator should explicitly reject or clear key logging (and similar secret-extraction knobs) before serving.
Useful? React with 👍 / 👎.
Summary
saluki-tls.Fixes #1910
Testing
Unit tests