[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Paulo Costa added the comment: Hello! Has this been addressed? I'm also working on implementing acme-tls/1 protocol and having exactly the same difficulties -- nosy: +paulo-raca ___ Python tracker

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Andrew Dailey added the comment: Okay, that makes sense. I appreciate the overview! What do you feel is the best way to "solve" this issue, then? Should the docs be updated to reflect the fact that ALPN info isn't available in the sni_callback? Or should some code be modified to make the

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Christian Heimes added the comment: The callback from context.alpn_callback would fire when OpenSSL handles the ALPN extension. Since the callback is triggered in the ClientHello phase of the handshake, you'll be able to replace the socket's context with another context. The OpenSSL codes

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Andrew Dailey added the comment: Yea, I noticed that through some of my digging. The ALPN callback is used to implement SSLContext.set_alpn_protocols() but full control of the callback isn't exposed. Aside from adjusting how the ALPN callback used, do you know of any other way to swap

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Christian Heimes added the comment: SSLContext.set_alpn_protocols() is a high level interface on top of SSL_CTX_set_alpn_select_cb(). Python doesn't directly expose the ALPN selector callback. The ssl module only provides a way to set a hard-coded callback that wraps

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Andrew Dailey added the comment: Yea, I'm still on the hunt for a better way to solve my primary problem: detect an acme-tls/1 ALPN protocol request during the TLS handshake so that I can swap out the context to one with the cert chain that Let's Encrypt is expecting to see. It seems like

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Christian Heimes added the comment: I don't see any way to fix the issue with our current API. OpenSSL 1.1.1 provides a new API SSL_client_hello_get0_ext() to access raw extension during early stage of ClientHello phase.

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Christian Heimes added the comment: I analysed the issue in comment https://bugs.python.org/issue43577#msg389222 -- nosy: +alex, dstufft, janssen, njs versions: +Python 3.10 ___ Python tracker

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

Change by Andrew Dailey : -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43582] SSLContext.sni_callback docs inaccurately describe available handshake info

New submission from Andrew Dailey : Hello, The documentation for SSLContext.sni_callback [0] seems to incorrectly describe the information available at that stage of the TLS handshake. According to the docs: Due to the early negotiation phase of the TLS connection, only limited methods and