Bug 1750921
| Summary: | NSS rejects records with large padding with SHA384 HMAC | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Hubert Kario <hkario> |
| Component: | nss | Assignee: | nss-nspr-maint <nss-nspr-maint> |
| Status: | CLOSED ERRATA | QA Contact: | Ivan Nikolchev <inikolch> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | low | ||
| Version: | 8.0 | CC: | dueno, inikolch, rrelyea, ssorce |
| Target Milestone: | rc | Keywords: | Triaged, ZStream |
| Target Release: | 8.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | nss-3.53.1-6.el8_2 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-08-03 13:01:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1809549 | ||
| Bug Blocks: | |||
reproducer is in https://github.com/tomato42/tlsfuzzer/pull/585 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3280 |
Description of problem: When NSS receives a record with maximum amount of application data (2^14 bytes) and maximum amount of padding (256 bytes) and the connection is using SHA384 HMAC, the record is rejected with record_overflow alert. Version-Release number of selected component (if applicable): both current upstream and nss-3.44.1-1.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. tlsfuzzer test-atypical-padding.py -e '2^14 bytes of AppData with 256 bytes of padding (SHA1 + Encrypt then MAC)' -e 'sanity - encrypt then MAC' 2. 3. Actual results: 2^14 bytes of AppData with 256 bytes of padding (SHA384) ... Error encountered while processing node <tlsfuzzer.expect.ExpectApplicationData object at 0x7f35de579310> (child: <tlsfuzzer.messages.AlertGenerator object at 0x7f35de579350>) with last message being: <tlslite.messages.Message object at 0x7f35de599410> Error while processing Traceback (most recent call last): File "scripts/test-atypical-padding.py", line 532, in main runner.run() File "/home/hkario/dev/tlsfuzzer/tlsfuzzer/runner.py", line 225, in run RecordHeader2))) AssertionError: Unexpected message from peer: Alert(fatal, record_overflow) Expected results: no errors Additional info: older versions of GnuTLS are known to generate this kind of records: https://gitlab.com/gnutls/gnutls/issues/811