Ignore failures when sending fatal alerts
In many places in TLS handling, some code detects a fatal error, sends
a fatal alert message, and returns to the caller. If sending the alert
fails, then return the error that triggered the alert, rather than
overriding the return status. This effectively causes alert sending
failures to be ignored. Formerly the code was inconsistently sometimes
doing one, sometimes the other.
In general ignoring the alert is the right thing: what matters to the
caller is the original error. A typical alert failure is that the
connection is already closed.
One case which remains not handled correctly is if the alert remains
in the output buffer (WANT_WRITE). Then it won't be sent, or will be
truncated. We'd need to either delay the application error or record
the write buffering notice; to be done later.
diff --git a/library/ssl_tls.c b/library/ssl_tls.c
index 096b111..713cb10 100644
--- a/library/ssl_tls.c
+++ b/library/ssl_tls.c
@@ -3473,7 +3473,6 @@
*/
static int ssl_parse_record_header( mbedtls_ssl_context *ssl )
{
- int ret;
int major_ver, minor_ver;
MBEDTLS_SSL_DEBUG_BUF( 4, "input record header", ssl->in_hdr, mbedtls_ssl_hdr_len( ssl ) );
@@ -3494,14 +3493,8 @@
ssl->in_msgtype != MBEDTLS_SSL_MSG_APPLICATION_DATA )
{
MBEDTLS_SSL_DEBUG_MSG( 1, ( "unknown record type" ) );
-
- if( ( ret = mbedtls_ssl_send_alert_message( ssl,
- MBEDTLS_SSL_ALERT_LEVEL_FATAL,
- MBEDTLS_SSL_ALERT_MSG_UNEXPECTED_MESSAGE ) ) != 0 )
- {
- return( ret );
- }
-
+ mbedtls_ssl_send_alert_message( ssl, MBEDTLS_SSL_ALERT_LEVEL_FATAL,
+ MBEDTLS_SSL_ALERT_MSG_UNEXPECTED_MESSAGE );
return( MBEDTLS_ERR_SSL_INVALID_RECORD );
}