mbedtls_ssl_conf_alpn_protocols with zero length list leads to invalid client hello

[dbuenzli]

Summary

Using mbedtls_ssl_conf_alpn_protocols with a zero length list (i.e. a C array of size 1 with a NULL element) leads clients to send an ALPN extension with a list length of 0. This is not allowed by RFC7301 §3.1: the length of the list must be at least two bytes (which implicitly entails at least one non-empty string, the text could make that explicit…).

System information

Mbed TLS version (number or commit id): 3.6.4

Expected behavior

When a context is configured with an empty list via mbedtls_ssl_conf_alpn_protocols, mbedtls should not send the ALPN extension during the handshake.

This could be implemented in two places:

1. In mbedtls_ssl_conf_alpn_protocols, conf->alpn_listcould be set to NULL if tot_len is 0 at this point

2. In ssl_write_alpn_ext, this condition could be turned into ssl->conf->alpn_list = NULL || *(ssl->conf->alpn_list) == NULL).

I thought 2. would be more robust, but OTOH mbedtls_ssl_conf_alpn_protocols is already in charge of checking other constraints on the list (no empty strings) so perhaps 1. is a better place.

Actual behavior

mbedtls sends a empty ALPN list. This leads peers to alert with a fatal Decode Error (50). Sample wireshark capture:

--->
Extension: application_layer_protocol_negotiation (len=2)
    Type: application_layer_protocol_negotiation (16)
    Length: 2
    ALPN Extension Length: 0
        [Expert Info (Warning/Protocol): Vector length 0 is smaller than minimum 2]
            [Vector length 0 is smaller than minimum 2]
            [Severity level: Warning]
            [Group: Protocol]
    ALPN Protocol
<---
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Decode Error)
    Content Type: Alert (21)
    Version: TLS 1.2 (0x0303)
    Length: 2
    Alert Message
        Level: Fatal (2)
        Description: Decode Error (50)