This is probably a consequence of turning on TLS 1.3. Can you check that setting MaxVersion to VersionTLS12 restores the expected behavior?

Unfortunately, this is due to TLS 1.3's protocol architecture: the client sends the client certificates, and then is immediately ready to send data to the server, without waiting for a reply. If no reads are done, the client will never consume the alert letting it know the handshake actually failed.

We might add a method to wait for the server finished if this turns out to be a common issue, but we can't make it the default behavior as it would add a round-trip and invalidate a lot of TLS 1.3's performance progress.

Sure, I'll give it a try (though I won't have access to my machine until later today). It being a 1.3 thing makes sense given its design, though it might be a bit unfortunate for connections which don't do any sort of special handshake.

My use case is IRC where I'm writing PASS/NICK to authenticate before I'd ever read anything back, so it's easy to consider the connection "ok" if nothing went wrong up until that point, then start handling incoming messages somewhere else.

That is indeed the case; setting the max version to 1.2 on either or both of the sides makes the behaviors match.

FYI, just discovered that this breaks traefik integration tests (https://github.com/containous/traefik/tree/v1.7
Branch: 1.7 (current stable)). Not sure how much it's related to the test itself. Haven't looked into it enough.

This is indeed an issue with how the test interacts with TLS 1.3: there is no way for the client Handshake to return an error for a rejected client certificate. The error must either be checked on the first Read, or on the server side.