[Bug]: TLS 1.3 RFC 8446 violations

[hey3e]

Contact Details

[email protected]

Version

5.6.3 928dd70

Description

ClientHello who lacks of "signature_algorithms" extension can still connect to examples/server/server, which violates rules in RFC8446 that "Clients which desire the server to authenticate itself via a certificate MUST send the "signature_algorithms" extension. If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert".

Reproduction steps

1. Use OpenSSL s_client.

• locate ssl/statem/extensions_clnt.c
• locate tls_construct_ctos_sig_algs function
• delete the code of adding sig_alg extensions: if (!WPACKET_put_bytes_u16(pkt, TLSEXT_TYPE_signature_algorithms) || !WPACKET_start_sub_packet_u16(pkt) || !WPACKET_start_sub_packet_u16(pkt) || !tls12_copy_sigalgs(s, pkt, salg, salglen) || !WPACKET_close(pkt) || !WPACKET_close(pkt)) { SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_TLS_CONSTRUCT_CTOS_SIG_ALGS, ERR_R_INTERNAL_ERROR); return EXT_RETURN_FAIL; } and make.

2. Make wolfssl.
3. Start server ./examples/server/server -v 4 -p 4433
4. Start client ./apps/openssl s_client -connect 127.0.0.1:4433 -tls1_3 -cert /wolfssl/certs/client-cert.pem -key /wolfssl/certs/client-key.pem -CAfile /wolfssl/certs/ca-cert.pem
5. Connected, which violates the RFC.

Relevant log output

No response

[kareem-wolfssl]

Hi @hey3e ,

Thank you for the report. I was unfortunately unable to get OpenSSL running but I have hacked our example client to not send sigalgs and I'm seeing the same behavior as you are, despite us having an error case to check for this in DoTls13ClientHello, it doesn't appear to be getting hit in this case. I am working on a fix for this now and will update you as I progress.

[kareem-wolfssl]

Hi @hey3e ,

Thank you again for the report. Please give #8356 and let me know if it fixes the issue for you.

We would love to hear more about your use case. Are you able to share any information on how you found this issue? Are you using any kind of analysis tool with wolfSSL? You are welcome to reach out to us at [email protected] if these details are sensitive.

[hey3e]

Thanks for your reply. The fix works. I'm designing a fuzzing tool which mutates fields in packets to fuzz peer. Unlike traditional fuzzers who focus on crash, I'm trying to find issues which should not be connected but connected in fact. I found this issue in wolfSSL because when this mutation is applied, other TLS implementations abort the handshake, so I believe there exists an error in wolfSSL or other implementations. Therefore, I refer to RFC to see if there has a requirement mentioning this case.