-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SocketInfo and alpn/sni negotiation #18
Conversation
A key question for the |
That's an interesting question and I might lean towards the latter. I am not aware of any protocols that may send SNI-influencing information in plaintext, but it feels more correct. |
I actually think it may make sense to have the new |
So instead of having |
Yeah, precisely. |
PR adding |
Gentle ping to update this to use the new |
Updated w/alpn and sni fields. I added the SocketInfo attribute for now on the Socket but we can definitely move it around. |
Adds
alpn
andsni
members to theSocketOptions
dictionary to address part of #14 and #15.Adds an
info
attribute toSocket
to retrieve the negotiatedalpn
protocol.I left the negotiated SNI out of the
info
attribute as it may be better to offer the full server certificate in that case and I don't see a concrete use case for it (the TLS connection will abort if SNI was ignored or incorrect).Note that
sni
andalpn
are valid forstarttls
connections as well so the specification allows them for eitheron
orstarttls
connections. An example of Server Name Indication withSTARTTLS
can be seen here: http://www.postfix.org/TLS_README.htmlOnce #12 is landed, it may make sense to update the text to specify that
ready
resolves when a TLS socket has been fully negotiated and