[Rust] aws-db-esdk enables the deprecated rustls feature of aws-sdk-dynamodb / aws-sdk-kms, forcing vulnerable rustls-webpki 0.101.7 on all downstream users

[nopeNoshishi]

Summary

aws-db-esdk depends on aws-sdk-dynamodb and aws-sdk-kms without default-features = false.
For both crates the default feature set is ["rustls", "default-https-client", "rt-tokio"], and the deprecated rustls feature enables the legacy hyper-0.14 HTTPS stack:

aws-sdk-dynamodb/default -> rustls -> aws-smithy-runtime/tls-rustls
  -> aws-smithy-http-client/legacy-rustls-ring -> rustls 0.21 -> rustls-webpki 0.101.7

rustls-webpki 0.101.7 is affected by three RustSec advisories, none of which have a fix available in the 0.101 line:

Advisory	Summary
RUSTSEC-2026-0098	Name constraints for URI names were incorrectly accepted
RUSTSEC-2026-0099	Name constraints were accepted for certificates asserting a wildcard name
RUSTSEC-2026-0104	Reachable panic in certificate revocation list parsing

Version

• aws-db-esdk 1.3.0 (also reproduces on 1.2.4)
• Resolved transitively: aws-sdk-dynamodb 1.120.0, aws-sdk-kms 1.114.0, aws-smithy-runtime 1.12.1, aws-smithy-http-client 1.2.0
• cargo 1.97.1, cargo-deny 0.19.0
• macOS (aarch64), but the resolution is platform independent

Steps to reproduce

Cargo.toml:

[package]
name = "repro"
version = "0.1.0"
edition = "2021"

[dependencies]
aws-db-esdk = "1.3.0"

$ cargo tree -i rustls-webpki@0.101.7
rustls-webpki v0.101.7
└── rustls v0.21.12
    ├── aws-smithy-http-client v1.2.0
    │   └── aws-smithy-runtime v1.12.1
    │       ├── aws-config v1.10.1
    │       │   └── aws-db-esdk v1.3.0
    │       │       └── repro v0.1.0
    │       ├── aws-runtime v1.9.1
    │       │   ├── aws-config v1.10.1 (*)
    │       │   ├── aws-sdk-dynamodb v1.120.0
    │       │   │   └── aws-db-esdk v1.3.0 (*)
    │       │   ├── aws-sdk-kms v1.114.0
    │       │   │   └── aws-db-esdk v1.3.0 (*)
...

For contrast, depending on the same SDK crates directly with default features disabled resolves only to a patched rustls-webpki:

[dependencies]
aws-sdk-dynamodb = { version = "1.120.0", default-features = false, features = ["default-https-client", "rt-tokio"] }
aws-sdk-kms = { version = "1.114.0", default-features = false, features = ["default-https-client", "rt-tokio"] }

$ cargo tree -e all | grep -o "rustls-webpki v[0-9.]*" | sort -u
rustls-webpki v0.103.14

The two feature edges that enable the legacy stack can be confirmed with:

$ cargo tree -e features -i aws-smithy-runtime
...
│   └── aws-smithy-runtime feature "tls-rustls"
│       ├── aws-sdk-dynamodb feature "rustls" (*)
│       └── aws-sdk-kms feature "rustls" (*)

In both cases the feature comes only from feature "default", which is enabled only by aws-db-esdk.

Why this cannot be worked around downstream

Cargo unifies features per crate, so a single dependency enabling rustls builds aws-smithy-runtime with tls-rustls for the entire graph.

In our workspace every AWS SDK crate we depend on directly already uses default-features = false with only default-https-client and rt-tokio enabled, exactly as recommended in awslabs/aws-sdk-rust#1257 under "How do I disable compiling the legacy hyper + rustls crates?". The legacy stack is still compiled in, purely because aws-db-esdk re-enables it. Removing aws-db-esdk from our dependency graph makes rustls 0.21 and rustls-webpki 0.101.7 disappear entirely.

We do not use the legacy hyper-0.14 connector at all — our clients are built with the default HTTPS client.

Suggested fix

Rather than dropping the legacy stack outright, aws-db-esdk could mirror what awslabs/aws-sdk-rust#1257 says the SDK crates themselves will eventually do: take it out of the default feature set, but keep it reachable through an explicit opt-in feature.

The announcement notes that the legacy stack is currently in the defaults so that pinning to an older BehaviorVersion works without extra configuration, and that once rustls leaves the defaults "users will have to re-enable the rustls feature manually at that time to keep the behavior version working." Exposing an equivalent feature on aws-db-esdk keeps that path open for anyone who needs it, while letting everyone else drop the duplicated TLS stack.

In both the runtime manifest and the published copy:

• DynamoDbEncryption/runtimes/rust/Cargo.toml
• releases/rust/db_esdk/Cargo.toml

[dependencies]
aws-sdk-dynamodb = { version = "1.103.0", default-features = false, features = ["default-https-client", "rt-tokio"] }
aws-sdk-kms = { version = "1.98.0", default-features = false, features = ["default-https-client", "rt-tokio"] }

[features]
default = ["non-fips"]
# Opt back in to the deprecated hyper-0.14 + rustls 0.21 stack, e.g. when pinning
# to a BehaviorVersion older than v2025_01_17.
legacy-https-client = ["aws-sdk-dynamodb/rustls", "aws-sdk-kms/rustls"]

default for those SDK crates is ["rustls", "default-https-client", "rt-tokio"], so this preserves current behaviour except that the legacy stack becomes opt-in.

Whether this warrants a major version bump of aws-db-esdk is your call — it is a behaviour change for users relying on feature unification, which is the same concern raised in that announcement's comment thread.

If keeping the legacy stack on by default is preferred for now, even just making it switchable (so downstream can build without it) would be enough to unblock users like us.

References

• awslabs/aws-sdk-rust#1257 — Announcement: Changes to the default HTTPS client stack