[Bug]: RFC 8446 violation: WolfSSL returns incorrect Alert when receiving malformed KeyShare extension

[aeyno]

Version

5.8.4

Description

A wolfSSL TLS 1.3 Server receiving a ClientHello with a malformed KeyShare extension (e.g. with no key inside) returns a IllegalParameter alert instead of a DecodeError alert.

According to the RFC 8446 section 6.2 : illegal_parameter : A field in the handshake was incorrect or inconsistent with other fields. This alert is used for errors which conform to the formal protocol syntax but are otherwise incorrect. and decode_error: A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This alert is used for errors where the message does not conform to the formal protocol syntax.

In our case the KeyShare extension is malformed, thus not conform the to the formal protocol syntax, meaning DecodeError should be sent instead of IllegalParameter

Impact

RFC violation.

Expected behavior

wolfSSL client should send an DecodeError Alert and abort the connection.

Reproduction steps

Here is an example of a TLS 1.3 ClientHello an incorrect KeyShare :

TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 114
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 110
Version: TLS 1.2 (0x0303)
Random: 0101010101010101010101010101010101010101010101010101010101010101
Session ID Length: 32
Session ID: 0303030303030303030303030303030303030303030303030303030303030303
Cipher Suites Length: 2
Cipher Suites (1 suite)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 35
Extension: supported_groups (len=4)
Type: supported_groups (10)
Length: 4
Supported Groups List Length: 2
Supported Groups (1 group)
Extension: signature_algorithms (len=6)
Type: signature_algorithms (13)
Length: 6
Signature Hash Algorithms Length: 4
Signature Hash Algorithms (2 algorithms)
Extension: key_share (len=6) secp384r1
Type: key_share (51)
Length: 6
Key Share extension
Client Key Share Length: 4
Key Share Entry: Group: secp384r1, Key Exchange length: 0
Group: secp384r1 (24)
Key Exchange Length: 0
Key Exchange: []
Extension: supported_versions (len=3) TLS 1.3
Type: supported_versions (43)
Length: 3
Supported Versions length: 2
Supported Version: TLS 1.3 (0x0304)

In raw hex : 16030300720100006e030301010101010101010101010101010101010101010101010101010101010101012003030303030303030303030303030303030303030303030303030303030303030002130101000023000a000400020018000d000600040401080400330006000400180000002b0003020304

Start a TLS 1.3 server:

./build/examples/server/server -v 4 -l 'TLS_AES_128_GCM_SHA256'  -p 3000

Send the ClientHello with the malformed KeyShare extension:

echo "16030300720100006e030301010101010101010101010101010101010101010101010101010101010101012003030303030303030303030303030303030303030303030303030303030303030002130101000023000a000400020018000d000600040401080400330006000400180000002b0003020304" | xxd -r -p | nc 127.0.0.1 3000

You should see the server respond an IllegalParameter alert.

Acknowledgements

This bug was found thanks to the tlspuffin fuzzer designed and developed by the tlspuffin team:

• Max Ammann
• Olivier Demengeon - Loria, Inria
• Tom Gouville - Loria, Inria
• Lucca Hirschi - Loria, Inria
• Steve Kremer - Loria, Inria
• Michael Mera - Loria, Inria

[kareem-wolfssl]

Hi @aeyno,

Thanks for the report. I was able to reproduce it and have a fix in progress.