QUIC transport parameters extension
botovq opened this issue · comments
Bug Report
System Information
| Type | Version/Name |
|---|---|
| Operating System Name | OpenBSD |
| Operating System Version | 7.1-current |
| Python version | 3.9.13 |
| tlslite-ng version | 0.8.0-alpha43 |
| tlsfuzzer revision | c56a143 |
Problem description
tlsfuzzer sends the QUIC transport parameters extension (extension number 57) in various test scripts, for example in test-tls13-shuffled-extentions.py, test-tls13-large-number-of-extensions.py, or test-large-hello.py. This extension MUST NOT be sent unless the transport is QUIC and endpoints that support the extension receiving it MUST abort the handshake with an unsupported extension alert, see the penultimate paragraph in RFC 9001, section 8.2.
While it is possible to work around this by excluding extension number 57 using the --exc command line flag or using -m in the case of test-large-hello.py, it would be nice if tlsfuzzer did not send this extension by default, or, alternatively, if it didn't fail on receiving an unsupported extension alert on sending it.
Describe how to reproduce the problem
We ran into this issue during our regular tlsfuzzer runs against LibreSSL head with this commit:
openbsd/src@db80cf4
Expected behaviour
tlsfuzzer does not send QUIC transport parameters or if it does it handles unsupported extension alerts gracefully.
Include errors or backtraces
multiple extensions 16377 ...
Error encountered while processing node ExpectServerHello() (child: <tlsfuzzer.expect.ExpectCertificate object at 0x4acdd4f5280>) with last message being: <tlslite.messages.Message object at 0x4ad338f47f0>
Error while processing
Traceback (most recent call last):
File "/usr/local/share/tlsfuzzer/scripts/test-large-hello.py", line 423, in main
runner.run()
File "/usr/local/lib/python3.9/site-packages/tlsfuzzer/runner.py", line 234, in run
raise AssertionError("Unexpected message from peer: " +
AssertionError: Unexpected message from peer: Alert(fatal, unsupported_extension)
yes, the scripts should be modified to not send them
they intentionally send low numbered extensions to break when an implementation includes new features, thus we need more tests...