lib/mbedtls
1
0
Fork 0
mirror of https://github.com/Mbed-TLS/mbedtls.git synced 2025-08-08 17:42:09 +03:00
Code Activity

Ignore failures when sending fatal alerts

Browse Source 
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.
This commit is contained in:
Gilles Peskine
2017-05-10 16:37:56 +02:00
parent 8498cb3687
commit c94f7352fa
3 changed files with 46 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
library/ssl_tls.c
View File

@@ -3473,7 +3473,6 @@ static int ssl_handle_possible_reconnect( mbedtls_ssl_context *ssl )
*/
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 @@ static int ssl_parse_record_header( mbedtls_ssl_context *ssl )
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 );
}