[gnutls-devel] GnuTLS | two KeyUpdates in one record do not get rejected with unexpected_message (#1789)

[Read-only notification of GnuTLS library development activities]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20260120/f9407f00/attachment.html>