You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the following ssl options passed to the sni_fun callback, we were expecting that a client capable of TLS 1.3 would have to negotiate to use TLS 1.2. However, based on the "Success" output from the server and the logging from the client, it appears the handshake completes successfully with TLS 1.3.
One oddity is that even when the connection_information reported from the socket is {protocol,'tlsv1.3'}, turning on debug logging shows that the last handshake to "finish" involves TLS 1.2.
To Reproduce
Call ssl:handshake/2, passing in the ssl options outlined below.
Yes, I believe this is a bug or two. OTP 22 did not have TLS-1.3 support and its state machine is quite different from the previous protocol versions. We will plan to fix this in our next sprint as believe it is a bigger job. I would also want to point out that your test program has a little problem, that is if you upgrade from a TCP connection, you will want to create the listen socket in passive mode {active, false} and supply {active, true} in the handshake options, otherwise TLS data might arrive at the wrong process.
Thanks for looking into this, and it's great to hear that there's a fix planned.
I would also want to point out that your test program has a little problem, that is if you upgrade from a TCP connection, you will want to create the listen socket in passive mode {active, false} and supply {active, true} in the handshake options, otherwise TLS data might arrive at the wrong process.
Got it. Thanks! I hope I remember that in the future.
Describe the bug
With the following ssl options passed to the sni_fun callback, we were expecting that a client capable of TLS 1.3 would have to negotiate to use TLS 1.2. However, based on the "Success" output from the server and the logging from the client, it appears the handshake completes successfully with TLS 1.3.
One oddity is that even when the connection_information reported from the socket is{protocol,'tlsv1.3'}
, turning ondebug
logging shows that the last handshake to "finish" involves TLS 1.2.To Reproduce
Call
ssl:handshake/2
, passing in the ssl options outlined below.If we add
CiphersAndVersions
as top-level options tossl:handshake/2
, then the TLS version is enforced:Finally, if we don't return options in the sni callback, we get a badmatch. This is a change from OTP 22.
Expected behavior
We were expecting that explicitly limiting the TLS versions in the
sni_fun
would cause negotiation to one of the TLS versions specified there.Affected versions
The following were run with
Erlang/OTP 24 [erts-12.1.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit]
and{ssl_app,"10.5.2"}
.The text was updated successfully, but these errors were encountered: