Skip to content

TlsAcceptCallbacks support for rustls backend#908

Open
dpfeifer2 wants to merge 1 commit into
cloudflare:mainfrom
dpfeifer2:feat/rustls-tls-accept-callbacks
Open

TlsAcceptCallbacks support for rustls backend#908
dpfeifer2 wants to merge 1 commit into
cloudflare:mainfrom
dpfeifer2:feat/rustls-tls-accept-callbacks

Conversation

@dpfeifer2

@dpfeifer2 dpfeifer2 commented Jun 12, 2026

Copy link
Copy Markdown

Support TlsAcceptCallbacks for the rustls backend

Ports the TlsAcceptCallbacks support 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); added set_certificate_chain_file() / set_private_key_file() and set_cert_resolver() for dynamic cert selection
TlsRef extended from an empty struct to expose post-handshake state.
handshake_with_callback() passes a populated TlsRef to handshake_complete_callback, matching the OpenSSL/BoringSSL behavior
• Added test_handshake_complete_callback integration test

Deviations from #833
• No webpki bypass: cert/key loading still goes through with_single_cert()
• Test uses the ring provider instead of aws_lc_rs

@dpfeifer2 dpfeifer2 force-pushed the feat/rustls-tls-accept-callbacks branch from b8dac96 to 58dd7b4 Compare June 12, 2026 11:30
@dpfeifer2 dpfeifer2 force-pushed the feat/rustls-tls-accept-callbacks branch from 58dd7b4 to 75df529 Compare June 12, 2026 13:59
@dpfeifer2 dpfeifer2 marked this pull request as ready for review June 12, 2026 14:10
@dpfeifer2

Copy link
Copy Markdown
Author

Hey @nojima , @johnhurt and @jsulmont , not much seems to have happened regarding #833 for a while. I would like to get the TlsAcceptCallbacks support for rustls. Given the change of #833 seems to have already been reviewed is there any chance we can get this PR merged (with the proposed split to leave out any unrelated changes from #833). Would appreciate it! Let me know if you have further comments I should address on this PR.
CC @stepancheg fyi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant