RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1410874 - malformed ALPN extension is rejected with incorrect alert messages
Summary: malformed ALPN extension is rejected with incorrect alert messages
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss
Version: 6.8
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: pre-dev-freeze
: ---
Assignee: nss-nspr-maint
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1511460
TreeView+ depends on / blocked
 
Reported: 2017-01-06 16:33 UTC by Hubert Kario
Modified: 2017-11-09 12:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1511460 (view as bug list)
Environment:
Last Closed: 2017-11-08 16:15:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1330615 0 None None None 2017-01-12 12:32:30 UTC

Description Hubert Kario 2017-01-06 16:33:53 UTC
Description of problem:

The extension is defined as follows:

   The "extension_data" field of the
   ("application_layer_protocol_negotiation(16)") extension SHALL
   contain a "ProtocolNameList" value.

   opaque ProtocolName<1..2^8-1>;

   struct {
       ProtocolName protocol_name_list<2..2^16-1>
   } ProtocolNameList;

When the ProtocolName length is 0 or the protocol_name_list length is 0, NSS doesn't send the expected decode_error alert:

   decode_error
      A message could not be decoded because some field was out of the
      specified range or the length of the message was incorrect.  This
      message is always fatal and should never be observed in
      communication between proper implementations (except when messages
      were corrupted in the network).

Instead it sends illegal_parameter and no_application_protocol alerts.

Version-Release number of selected component (if applicable):
nss-3.27.1-12.el6.x86_64

How reproducible:
always

Steps to Reproduce:
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
git checkout alpn-test # won't be necessary in future
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
git clone https://github.com/tomato42/tlslite-ng.git .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
popd
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -nodes -batch -subj /CN=localhost
openssl pkcs12 -export -passout pass:  -out localhost.p12 -inkey localhost.key -in localhost.crt
mkdir nssdb
certutil -N -d sql:nssdb --empty-password
pk12util -i localhost.p12 -d sql:nssdb -W ''
./selfserv -d sql:./nssdb -p 4433 -V tls1.0: -H 1 -n localhost -Q
# in another terminal, same directory
PYTHONPATH=tlsfuzzer python tlsfuzzer/scripts/test-alpn-negotiation.py 'empty extension' 'empty list'

Actual results:
empty extension ...
Error encountered while processing node <tlsfuzzer.expect.ExpectAlert object at 0x2dd9790> (child: <tlsfuzzer.expect.ExpectClose object at 0x2dd97d0>) with last message being: <tlslite.messages.Message object at 0x2dd9f90>
Error while processing
Traceback (most recent call last):
  File "test-alpn-negotiation.py", line 218, in main
    runner.run()
  File "/tmp/tmp.pejrU9l8lU/tlsfuzzer/tlsfuzzer/runner.py", line 168, in run
    node.process(self.state, msg)
  File "/tmp/tmp.pejrU9l8lU/tlsfuzzer/tlsfuzzer/expect.py", line 542, in process
    raise AssertionError(problem_desc)
AssertionError: Alert description 47 != 50

empty list ...
Error encountered while processing node <tlsfuzzer.expect.ExpectAlert object at 0x2dd9650> (child: <tlsfuzzer.expect.ExpectClose object at 0x2dd9690>) with last message being: <tlslite.messages.Message object at 0x2ddaf10>
Error while processing
Traceback (most recent call last):
  File "test-alpn-negotiation.py", line 218, in main
    runner.run()
  File "/tmp/tmp.pejrU9l8lU/tlsfuzzer/tlsfuzzer/runner.py", line 168, in run
    node.process(self.state, msg)
  File "/tmp/tmp.pejrU9l8lU/tlsfuzzer/tlsfuzzer/expect.py", line 542, in process
    raise AssertionError(problem_desc)
AssertionError: Alert description 120 != 50

Expected results:
empty extension ...
OK

empty list ...
OK

Additional info:

Comment 2 Kai Engert (:kaie) (inactive account) 2017-01-11 15:42:20 UTC
If you find deficiencies in NSS that aren't specific to our packaging, please always report an upstream bug.

Comment 3 Kai Engert (:kaie) (inactive account) 2017-01-12 12:46:49 UTC
EKR / Upstream has argued this isn't an issue with TLS 1.2, only with TLS 1.3 which we won't enable yet.

Comment 4 Hubert Kario 2017-01-12 13:56:42 UTC
the decode_error wording comes from RFC 5246, not from TLS1.3 draft...

I understood his comment as "while in TLS1.2 we might have been able to weasel out, TLS 1.3 is too precise in that regard so it should be fixed everywhere"

Comment 5 Kai Engert (:kaie) (inactive account) 2017-08-31 14:03:53 UTC
Upstream hasn't made progress in 7 months. It seems this is considered low priority. Unlikely to get fixed for 6.10

Comment 6 Kai Engert (:kaie) (inactive account) 2017-11-08 16:15:38 UTC
imprecise error message doesn't meet the criteria for priority items for 6.10, I'm marking it as wontfix, to indicate we won't track it for 6.10

it's good that you have reported this upstream, to get this fixed eventually.


Note You need to log in before you can comment on or make changes to this bug.