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
modifi
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
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
Change by Andrew Dailey :
--
nosy: +christian.heimes
___
Python tracker
<https://bugs.python.org/issue43582>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Andrew Dailey added the comment:
I'm glad that the info I provided was helpful! I'll go ahead and create another
issue for the misleading docs surrounding SSLContext.sni_callback. Thanks for
looking into this and coming up with a fix so quickly.
I do have one more question: does python
New submission from Andrew Dailey :
Hello,
I think I might've stumbled onto an oversight with how an SSLSocket handles
overwriting its SSLContext within an sni_callback. If both "_msg_callback" and
"sni_callback" are defined on an SSLContext object and the sni_callback
