Broken TLS 1.3 handshake error handling

[akokhanovskyi]

When a broker rejects the client cert, the expected token error from Client.Connect() is Network Error : remote error: tls: bad certificate. The actual error with TLS 1.3 is Network Error : %!s(<nil>). TLS 1.3 is the default with go 1.13; opt-out will be removed in go 1.14.

Why this happens:

In TLS 1.3 the client is the last one to speak in the handshake, so if it causes an error to occur on the server, it will be returned on the client by the first Read, not by Handshake. For example, that will be the case if the server rejects the client certificate.

(see go 1.12 release notes)

According to the above:

• tls.DialWithDialer() yields no error (see net.go:76)
• openConnection() also returns a nil error (client.go:255)
• client.connect() fails with return code packets.ErrNetworkError (client.go:281)
• token.setError() sets inaccurate error (client.go:324): err is still nil, which leads to an fmt error (%!s(<nil>)).

I think, this can be fixed by properly inspecting the error returned by packets.ReadPacket() (client.go:478). In case of a rejected client cert, this is a net.OpError remote error with alertBadCertificate. I'm not well-versed in the overall library design, though, so maybe there are better ideas.

[Dunken]

In case of a rejected client cert, this is a net.OpError remote error with alertBadCertificate.

Did you verify this? I always get a alertDecryptError.

[akokhanovskyi]

I tested with an intentionally wrong client-presented x.509 cert that was not trusted by the server CA. Your error seems to be different: alertDecryptError normally means that the server is somehow unable to decrypt the first encrypted message from the client ("Finished").

[akokhanovskyi]

@alsm Could you please review #452? Looking forward to your feedback!