TlsAcceptCallbacks support for rustls backend#908
Conversation
b8dac96 to
58dd7b4
Compare
58dd7b4 to
75df529
Compare
|
Hey @nojima , @johnhurt and @jsulmont , not much seems to have happened regarding #833 for a while. I would like to get the |
|
Author of #833 here — this is the right split, thanks for picking it up @dpfeifer2, and sorry for letting mine stall. I got dragged into other work, and on our end it's since been decided to stick with the OpenSSL route for now. The TlsAcceptCallbacks support is the uncontroversial core, and keeping cert/key loading on with_single_cert() with set_cert_resolver() as the opt-in escape hatch is exactly what @nojima asked for: the default webpki behavior is untouched. I'm closing #833 in favor of this. LGTM. |
|
I'll take a look at this PR over the weekend. |
Support TlsAcceptCallbacks for the rustls backend
Ports the
TlsAcceptCallbackssupport from upstream #833, excluding the parts flagged in review there: that PR bundles unrelated changes (intentional webpki policy bypass on cert loading, custom ServerCertVerifier support in the connector) which @nojima asked to split into a separate PR (#833 (comment)) for independent security discussion. This PR takes only the callbacks feature.Changes
•
TlsSettings::with_callbacks(cb)now works with rustls (previously returned an error); addedset_certificate_chain_file()/set_private_key_file()andset_cert_resolver()for dynamic cert selection•
TlsRefextended from an empty struct to expose post-handshake state.•
handshake_with_callback()passes a populatedTlsReftohandshake_complete_callback, matching the OpenSSL/BoringSSL behavior• Added
test_handshake_complete_callbackintegration testDeviations from #833
• No webpki bypass: cert/key loading still goes through with_single_cert()
• Test uses the ring provider instead of aws_lc_rs