GHSA-4pj9-g833-qx53

Summary

An inverted-boolean bug in lettre's boring-tls integration silently disables TLS hostname verification for callers using the default (strict) configuration. An on-path attacker presenting any chain-valid certificate for any domain can intercept SMTP submission, including PLAIN/LOGIN credentials and message contents, against any lettre user built with the boring-tls feature. Other TLS backends (native-tls, rustls) are unaffected.

Details

boring's SslConnectorBuilder::set_verify_hostname(bool) / verify_hostname(bool) API takes a verify flag — true means enforce hostname verification, false means skip it. (Boring docs: https://docs.rs/boring/latest/boring/ssl/struct.ConnectConfiguration.html#method.set_verify_hostname) lettre's TlsParametersBuilder exposes the opposite-named flag accept_invalid_hostnames: bool — true means accept invalid (skip verification), false means verify. lettre passes this flag directly to boring at both TLS-upgrade sites, inverting the semantics: src/transport/smtp/client/net.rs:202 (sync) .verify_hostname(*accept_invalid_hostnames) src/transport/smtp/client/async_net.rs:377 (async) config.set_verify_hostname(accept_invalid_hostnames); Concrete behaviour under boring-tls:

• accept_invalid_hostnames = false (the strict default) → set_verify_hostname(false) → hostname verification SKIPPED (wrong; the caller asked for strict verification)
• accept_invalid_hostnames = true (explicit opt-in to "dangerous") → set_verify_hostname(true) → hostname verification ENFORCED (wrong; the caller opted into accepting any name) Boring's own warning on set_verify_hostname: "If hostname verification is not used, any valid certificate for any site will be trusted for use from any other. This introduces a significant vulnerability to man-in-the-middle attacks." native-tls (src/transport/smtp/client/tls.rs:355) uses...