mbedtls_ssl_handshake() and fatal alerts
In 2.2.1, mbedtls_ssl_handshake() can return MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE, but, as far as I can tell, there's no way to find out exactly what fatal alert was received. I'd like to be able to give more detailed information to the user when there's a failure, plus I might take some action depending on the problem.
Currently there is only the debug report as a way to receive the type of alert.
Can you suggest actions you would take on different fatal messages that would help the next handshake?
In general it requires human interaction of some kind.
Right, I wouldn't expect to fix the problem in my code, but instead of telling the user "Handshake with this server failed because...I don't know, it just failed", I could tell them what was wrong.
That's what our debug-info is for.
But technically you can access the alert message type in
ssl->in_msg (Which is used in the debug message )
(But beware, this might change in future versions)
tries out the debug system
Let's see...with threshold 1, I get a fair amount of
mbedtls_ssl_flush_output() returned -26752 (-0x6880)
mbedtls_ssl_write_record() returned -26752 (-0x6880)
mbedtls_ssl_flush_output() returned -78 (-0x004e)
mbedtls_ssl_write_record() returned -78 (-0x004e)
mbedtls_ssl_send_alert_message() returned -78 (-0x004e)
going by that wouldn't be of interest to the user.
In any case, this is a gui program, and we do print some messages to stdout and stderr, but the proportion of users who run it from a cmdline is small. So I would have to filter through the debug output for that "is a fatal alert message..." string to display my own message in a dialog, which is probably not safer than in_msg. Hmm...
ssl->in_msg is not going to change anytime soon, unless there are radical changes. I would think that safer than the message filtering..
Okay, I'll use that, then.