There are 3 possible errors which the server can send before the handshake succeeded:

too many connections
server ran out of threads
a TLS error/alert, e.g. no matching protocol, unsupported cipher suite, ....

plugin errors will be sent after the handshake, since the client hello packet will be encrypted.

That is fewer than I thought, which is good to know. I do think it is important to know which one of these has been hit, particularly a differentiator between the first two and the last one. At least logged somewhere for debugging / post-mortem purposes. Even if the original error code is not maintained.

georg wrote:

There are 3 possible errors which the server can send before the handshake succeeded:

• too many connections
• server ran out of threads
• a TLS error/alert, e.g. no matching protocol, unsupported cipher suite, ....

These cases need to be distinguished:

The "too many connections" and "out of threads" errors are application-level errors: they are sent *by the server to the client.

The fact that these are sent by the server before the TLS handshake happens is bad. As I described above, the client may vary its retry behavior based on exactly what error it receives, and this could enable a variety of attacks… which rapidly get much, much more serious if the client starts automatically trying to connect to different servers based on errors it receives.

• TLS errors/alerts are transport-level errors: they are generated by the client as a result of an inability to construct a satisfactorily-secure TLS channel between it and the server. Assuming they all get the same error code (CR_SSL_CONNECTION_ERROR, I think?) then an attacker can prevent a connection from succeeding, but can't cause a client to vary its behavior based on the contents of the error. (If a client receives a CR_SSL_CONNECTION_ERROR, it shouldn't vary its behavior based on the detailed error message; "TLS alert X" vs "not allowed cipher Y", etc.)

TheLinuxJedi, perhaps my statements above about this previously were unclear: it's not that the client needs to hide the details of any error which it encounters before the TLS handshake. It's just that the client should hide the details of an application-level error which it appears to have received from the server before the TLS handshake (because that error could actually be from a MITM attacker).

And indeed that is what my PR does in its current form: "Do not trust error packets received from the server prior to TLS handshake completion". It does not prevent the client from returning unique error codes for other conditions which are unrelated to application-layer traffic ("hostname not found", "TLS alert", "conflicting connection parameters don't make sense", etc).

I've counted 13 errors that a server can legally send before TLS is established.

Four of them can only happen before authentication (before TLS, if requested):

• ER_BAD_HOST_ERROR
• ER_CANT_CREATE_THREAD
• ER_HOST_IS_BLOCKED
• ER_HOST_NOT_PRIVILEGED

Others can happen before or after TLS:

• EE_OUTOFMEMORY
• ER_CONNECTION_KILLED
• ER_HANDSHAKE_ERROR
• ER_NET_FCNTL_ERROR
• ER_NET_PACKET_TOO_LARGE
• ER_NET_READ_ERROR
• ER_NET_READ_INTERRUPTED
• ER_NET_UNCOMPRESS_ERROR
• ER_OUT_OF_RESOURCES

Even if we only consider the first four errors, ER_CANT_CREATE_THREAD is transient and the client might want to retry, ER_HOST_IS_BLOCKED and ER_HOST_NOT_PRIVILEGED are permanent. A client cannot just ignore those errors. And in the MitM case they can be spoofed indeed. I don't see how you can possibly solve this.

ER_ACCESS_DENIED can never come before TLS and a client can safely ignore it and all errors that aren't in the list above. But errors from the above list are more than enough for MitM to use.

Connector/C PR #223 has now been merged to the 3.3 branch, but not yet tagged in a release.