Avoid misleading error information for delayed TLS 1.3 alerts

[JeppeTh]

When it comes to mTLS TLS 1.3 is not very well designed since the client considers the handshake to be successful before the server has performed it's verification of the client.

If that verification fails it means that the client will receive the TLS alert after ssl:connect has successfully returned.
For such case socket operations like send, setopts etc. will return {error, closed | einval} instead of the tls_alert().
This all leads to that the Gun users get misleading failures.

This can be solved by letting gun check it's message queue for {ssl_error, Socket, tls_alert()} when failing with closed | einval.
Needs to be done with a short timeout since the error can be returned before the process receives the alert.

Requires active mode from the start (at least it makes things simpler).

To avoid delay of normal close this can be avoided if TLS 1.3 isn't a candidate, or if the socket has been confirmed (=data received).

[essen]

Can you prepare a small example using only the ssl application?

[JeppeTh]

You meant how to reproduce right? I made some simple example
delayed_tls_alert.tar.gz

Example output:

48> delayed_tls_alert:run(4004).
delayed_tls_alert:run(4004).
Client successfully connected
send result: ok
send result: ok
send result: ok
Server Handshake result:{error,
{tls_alert,
{certificate_required,
"TLS server: In state wait_cert at tls_handshake_1_3.erl:1485 generated SERVER ALERT: Fatal - Certificate required\n certificate_required"}}}
send result: {error,closed}
{error,closed}

[essen]

Yes, thank you.

[essen]

I don't think we need to do anything about this, as this has been fixed in OTP in erlang/otp#8823

[JeppeTh]

That doesn't change the above behaviour. There were situations where the alert could be lost. ssl:send will never return any alert regardless of that fix.

…

-------- Original message -------- From: Loïc Hoguin ***@***.***> Date: 06/11/2024 14:40 (GMT+01:00) To: ninenines/gun ***@***.***> Cc: JeppeTh ***@***.***>, Author ***@***.***> Subject: Re: [ninenines/gun] Avoid misleading error information for delayed TLS 1.3 alerts (Issue #341) I don't think we need to do anything about this, as this has been fixed in OTP in erlang/otp#8823<erlang/otp#8823> — Reply to this email directly, view it on GitHub<#341 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABBEXN7MPYRCS2POJX7AASLZ7IL3BAVCNFSM6AAAAABRF6MT5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZG44DCNZTGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[essen]

Let me see with OTP team if this should be done for more functions.

[JeppeTh]

setopts can fail as well at least.

…

-------- Original message -------- From: Loïc Hoguin ***@***.***> Date: 06/11/2024 15:46 (GMT+01:00) To: ninenines/gun ***@***.***> Cc: JeppeTh ***@***.***>, Author ***@***.***> Subject: Re: [ninenines/gun] Avoid misleading error information for delayed TLS 1.3 alerts (Issue #341) Let me see with OTP team if this should be done for more functions. — Reply to this email directly, view it on GitHub<#341 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABBEXN6LWFQZPI7YDDFF523Z7ITTXAVCNFSM6AAAAABRF6MT5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZHE2DMMBXGQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[JeppeTh]

I updated my example a bit - additional example output of some function calls. I also added a receive in the end to check if there's an alert in the queue

59> delayed_tls_alert:run(4004).
delayed_tls_alert:run(4004).
Client successfully connected
Server Handshake result:{error,
{tls_alert,
{certificate_required,
"TLS server: In state wait_cert at tls_handshake_1_3.erl:1485 generated SERVER ALERT: Fatal - Certificate required\n certificate_required"}}}
ssl:negotiated_protocol returned {error,closed}
ssl:setopts returned {error,closed}
ssl:connection_information returned: {error,closed}
ssl:send returned {error,closed}
Received {tls_alert,{certificate_required,[84,76,83,32,99,108,105,101,110,116,58,32,73,110,32,115,116,97,116,101,32,99,111,110,110,101,99,116,105,111,110,32,114,101,99,101,105,118,101,100,32,83,69,82,86,69,82,32,65,76,69,82,84,58,32,70,97,116,97,108,32,45,32,67,101,114,116,105,102,105,99,97,116,101,32,114,101,113,117,105,114,101,100,10]}} after 0ms