Create a TLS connection with a mismatched certificate (this is in a unit test, which was testing the "bad path").
What did you expect to see?
With <=TLSv12, I get an error from DialWithDialer(). This feels like the natural time to return connection set-up errors and it makes it more obvious to the caller that the issue is with the parameters of the connection.
(We had this pinned because tests started failing when we updated to go v1.13 so we made a quick fix; I'm just coming back to that to investigate...)
What did you see instead?
With <=TLSv13, I get no error from DialWithDialer(), but later reads fail with
remote error: tls: bad certificate type=""
for example. So, looks like there's no compromise in security but the error appears as a problem with the established connection rather than a problem with establishing the connection in the first place.
The text was updated successfully, but these errors were encountered:
This is unfortunate but expected behavior, which is due to how TLS 1.3 works at the protocol level, and can't be fixed by the implementation. In TLS 1.3, the client sends the client certificates just before declaring the handshake over, and doesn't get to hear from the server again before sending application data. Waiting to hear back would introduce a whole round-trip, with a significant performance cost.
We've only seen this affect tests, since as you observed the error will be detected on the first Read invocation.