Andrew Dailey <steveday168@gmail.com> 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 contexts once the selected ALPN proto is known but not before it's too late? As I said before, I'm not super familiar with Python / OpenSSL internals but maybe overriding SSLSocket.do_handshake() would suffice? I don't want this issue to get too far off track. I'm still doing research on how I'd go about drafting and submitting a formal patch here on the issue tracker. I'm new to this process but definitely want to help out as much as I can. Here's my current idea for how to adjust the documentation given the current behavior / capabilities. CURRENT: Due to the early negotiation phase of the TLS connection, only limited methods and attributes are usable like SSLSocket.selected_alpn_protocol() and SSLSocket.context. SSLSocket.getpeercert(), SSLSocket.getpeercert(), SSLSocket.cipher() and SSLSocket.compress() methods require that the TLS connection has progressed beyond the TLS Client Hello and therefore will not contain return meaningful values nor can they be called safely. REVISED: Based on the value of `sni_name`, a new SSLContext can be created and attached to the current SSLSocket. Due to the early negotiation phase of the TLS connection, only the Client Hello will have occurred by the time this callback is called. Methods and attributes such as SSLSocket.selected_alpn_protocol(), SSLSocket.getpeercert(), SSLSocket.cipher(), and SSLSocket.compress() require that the TLS connection has progressed beyond the TLS Client Hello and therefore will not contain return meaningful values nor can they be called safely. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue43582> _______________________________________