GnuTLS | two KeyUpdates in one record do not get rejected with unexpected_message (#1789)
Read-only notification of GnuTLS library development activities <[email protected]>
| Newsgroups | gmane.comp.encryption.gpg.gnutls.devel |
|---|---|
| Message-ID | <[email protected]> |
Alexander Sosedkin created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1789 ## Description of problem: processing two KeyUpdate handshake messages in a single TLS 1.3 record doesn't abort with `unexpected_message`, but rather leads to a subsequent `bad_record_mac`. ## Version of gnutls used: gnutls-3.8.11-5.fc43 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Fedora ## How reproducible: reliably Steps to Reproduce: * set up tlsfuzzer * spin up a gnutls server * run `test-tls13-keyupdate.py` against the gnutls server ## Actual results: both KeyUpdate messages are processed by gnutls, which then fails with `bad_record_mac`. ## Expected results: gnutls implements stricter validation prescribed in [RFC 8446 5.1](https://www.ietf.org/rfc/rfc8446.html#section-5.1), refuses to process the second KeyUpdate and aborts with an `unexpected_message`: > Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. ## Testing: I plan to update tlsfuzzer submodule in !2055 and waive the test initially. Then the validation could be just removing the expected failure from tests/suite/tls-fuzzer/gnutls-nocert-tls13.json. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1789 You're receiving this email because of your account on gitlab.com. _______________________________________________ Gnutls-devel mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-devel