yanwucai
commented
8 months ago This is a bug in NetXDuo TLS and your fix looks good.
Open dougbenedict opened 8 months ago
yanwucai
commented
8 months ago This is a bug in NetXDuo TLS and your fix looks good.
Version 6.2.1 of NetXDuo
If a TLS1.3 payload includes padding then the processing in _nx_secure_tls_process_record() does not handle it correctly.
RFC 8446, Section 5.4: The padding sent is automatically verified by the record protection mechanism; upon successful decryption of a TLSCiphertext.encrypted_record, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet. This non-zero octet is the content type of the message.
The processing in _nx_secure_tls_process_record() does not perform this step. As a result when the message_type is read from the end of the decrypted payload at line 313 a message type of zero is read. The code generates an alert that is sent to the remote host and the connection is aborted.
The MbedTLS test programs ssl_client2 and ssl_server2 can be used to reproduce this issue. I used MbedTLS version 3.4.0.
ssl_server2 ca_file=ec-cacert.pem crt_file=device-cert.pem key_file=device-key.pem server_port=50007 auth_mode=required ssl_client2 server_addr=192.168.1.184 ca_file=ec-cacert.pem crt_file=device-cert.pem key_file=device-key.pem server_port=50007 server_name="NJSASC" auth_mode=required
nx_secure_tls_process_record.zip
In the attached version of nx_secure_tls_process_record.c, I added a new routine to trim the trailing zero octets from the decrypted payload. The routine is _nx_secure_tls_packet_trim_trailing_zeros(). With this change, padded TLS 1,3 payloads are processed correctly.