Change TLS provider to rustls?

[HTHou]

Motivation

The client currently implements its optional tls feature with native-tls. Replace that implementation with a rustls-backed transport.

rustls offers several advantages for this project:

• Its TLS protocol implementation is written in memory-safe Rust, reducing exposure to memory-safety bugs in protocol processing.
• It supports modern TLS versions only (TLS 1.2 and TLS 1.3).
• It provides explicit control over trust anchors, certificate verification, client authentication, protocol policy, and the cryptographic provider.
• It does not delegate TLS protocol processing or certificate-verification policy to a platform TLS implementation or OpenSSL.

This migration does not require native TLS support from the Thrift crate. The client already establishes TLS below Thrift's framed transport, which only requires Read and Write streams, so the existing thrift = "0.23" dependency can remain unchanged.

Apache Thrift has also merged optional rustls-backed transports in apache/thrift#3638. A future Thrift upgrade may allow this client to remove some of its local TLS stream-adapter code, but it is not a prerequisite for this migration.

Selected design

• Replace the current native-tls implementation behind the existing tls Cargo feature with rustls 0.23.
• Use the ring crypto provider and support TLS 1.2/1.3.
• Keep the existing thrift = "0.23" dependency.
• Load native trust roots with rustls-native-certs, append any PEM roots supplied through ca_cert_path, and use rustls/WebPKI for certificate-chain and hostname verification on every platform. Platform APIs supply roots only; they do not define verification semantics.
• Preserve the existing public TLS configuration behavior:
  • custom CA certificates in PEM format;
  • hostname/SNI override;
  • optional client certificate and PKCS#8 private key for mutual TLS;
  • an explicitly unsafe option for accepting invalid certificates.
• Keep the local shared TLS stream adapter unless a later Thrift upgrade can replace it without losing the existing TCP connection-timeout behavior.

Acceptance criteria

• Plain TCP behavior remains unchanged when the tls feature is disabled.
• TLS connections work with normal system trust roots and with a user-supplied CA certificate.
• Certificate-chain and hostname verification use the same WebPKI semantics across supported platforms.
• Hostname verification and domain_override continue to work.
• Mutual TLS works with the existing client certificate/key configuration.
• Invalid or untrusted certificates fail unless the unsafe opt-out is explicitly enabled.
• TLS tests and CI cover Linux, macOS, and Windows where practical.
• README and Rust API documentation describe the selected trust-store and crypto-provider behavior.