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).
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).