crypto-fips doesn't reach every TLS path: legacy client by BehaviorVersion, and s2n-tls

[yychen23]

#4681's premise was that TLS was already handled, since #966 added rustls-aws-lc-fips. That holds
only for the hyper 1.x client. Two TLS paths a customer can realistically be on are not covered by
aws-smithy-runtime/crypto-fips (and so not by the fips feature on generated SDK crates).

1. The legacy client, selected by BehaviorVersion

A generated SDK crate compiles both HTTP stacks by default, and BehaviorVersion picks between them
in aws-smithy-runtime/src/client/defaults.rs:

if behavior_version.is_at_least(BehaviorVersion::v2026_01_12()) {
    // hyper 1.x stack (rustls 0.23 + AWS-LC)
} else {
    // legacy hyper 0.14.x (rustls 0.21 + ring)
}

So an application pinned below v2026_01_12 — common enough, for stability — gets FIPS signing and
checksums over ring. cargo tree --features fips -i ring shows it.

This now logs a warning naming both ways out (move to v2026_01_12 or later, or drop the legacy
stack). Open question is whether a warning is enough, or whether the fips feature should make it
harder to get wrong — the alternative being to have it also enable default-https-client, which
overrides a deliberate client choice.

2. s2n-tls, whose FIPS mode isn't forwarded

s2n-tls is not selectable from aws-smithy-runtime or from a generated crate at all; it has to be
installed as an explicit HTTP client via aws-smithy-http-client. It is also already AWS-LC-based:
s2n-tls-sys's feature table has

fips = ["aws-lc-rs/fips"]

— the same validated module this design uses. (Checked on main and at a release tag of the 0.3.x
bindings series; rust-runtime/Cargo.lock resolves s2n-tls-sys 0.3.43.) So an s2n-tls build can
have FIPS TLS, but only if the consumer enables that feature in their own manifest, because
aws-smithy-http-client's s2n-tls feature doesn't forward it. That's the existing TODO(hyper1): add a way to enable the fips feature flag in s2n-tls in rust-runtime/aws-smithy-http-client/Cargo.toml.

Closing that looks small: an s2n-tls-fips feature on aws-smithy-http-client forwarding
s2n-tls?/fips, which crypto-fips could then enable weakly alongside rustls-aws-lc-fips. The TLS
arm would then cover both implementations instead of one.

A custom connector can't be detected from this layer and stays documentation-only.