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 1326886 - GnuTLS server rejects connections that do not advertise support for SHA-1 signature algorithms
Summary: GnuTLS server rejects connections that do not advertise support for SHA-1 sig...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gnutls
Version: 6.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Nikos Mavrogiannopoulos
QA Contact: Hubert Kario
URL:
Whiteboard:
Depends On:
Blocks: 1339222 1343211
TreeView+ depends on / blocked
 
Reported: 2016-04-13 16:14 UTC by Hubert Kario
Modified: 2017-03-21 09:03 UTC (History)
2 users (show)

Fixed In Version: gnutls-2.12.23-17.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-21 09:03:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:0574 0 normal SHIPPED_LIVE Moderate: gnutls security, bug fix, and enhancement update 2017-03-21 12:23:04 UTC

Description Hubert Kario 2016-04-13 16:14:11 UTC
Description of problem:
GnuTLS servers configured to support TLSv1.2 protocol will reject connections that in the Client Hello Signature Algorithms extension indicate support for just one hash if that hash is not SHA-1.

Version-Release number of selected component (if applicable):
gnutls-2.8.5-19.el6_7.x86_64

How reproducible:
Always

Steps to Reproduce:
git clone https://github.com/tomato42/tlsfuzzer.git
pushd tlsfuzzer
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
gnutls-serv --http --port 4433 --x509keyfile localhost.key --x509certfile localhost.crt --disable-client-cert --priority NORMAL:+VERS-TLS1.2
# in another terminal, in the same directory:
PYTHONPATH=tlsfuzzer/ python tlsfuzzer/scripts/test-dhe-rsa-key-exchange-signatures.py

Actual results:
All connections that don't use sha1 hash are aborted with handshake_failure alert or the server forces algorithm not advertised by client

Expected results:
all connections successful

Additional info:

Comment 2 Nikos Mavrogiannopoulos 2016-08-09 12:07:02 UTC
After checking the behavior of gnutls, is that this is the expected behavior according to TLS 1.2. That protcol requires "If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension."

Your generated certificate uses sha1, thus any client requests which require another hash than the one present in the certificate are dropped. Please elaborate on the actual issue, rather than the behavior of the test suite, because it is not clear what the test suite is checking for.

Comment 3 Nikos Mavrogiannopoulos 2016-08-09 16:44:46 UTC
This protocol requirement was removed in later versions of gnutls to promote interoperability. I've backported that patch, which would fix the described behavior.

Comment 10 Hubert Kario 2016-10-21 13:56:26 UTC
There are two more problems:

 1. GnuTLS will sign Server Key Exchange message with md5+rsa signature
    algorithm if that pair is the first one advertised in signature_algorithms
    extension
 2. GnuTLS will sign Server Key Exchange message with sha1+rsa signature
    algorithm if none of the signature algorithms advertised by client are
    recognized by server instead of aborting the connection with
    handshake_failure

Point 2 is a RFC violation:

   If the client does not support the default algorithms (...),
   it MUST send the
   signature_algorithms extension, listing the algorithms it is willing
   to accept.

("default algorithms" refers to sha1+rsa, sha1+dsa and sha1+ecdsa pairs)

   If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension.  Note that there is a possibility for inconsistencies
   here.  For instance, the client might offer DHE_DSS key exchange but
   omit any DSA pairs from its "signature_algorithms" extension.  In
   order to negotiate correctly, the server MUST check any candidate
   cipher suites against the "signature_algorithms" extension before
   selecting them.  This is somewhat inelegant but is a compromise
   designed to minimize changes to the original cipher suite design.

You can use the test-sig-algs.py script from sig-algs branch of the repo to test it.

Comment 12 Nikos Mavrogiannopoulos 2016-10-21 15:16:35 UTC
Thanks, nice catch. I have a fix for the MD5-related cases (1):
https://gitlab.com/gnutls/gnutls/merge_requests/121

What I am unsure of is (2). If no option is recognized by the server attempting to proceed with the default (SHA1) for TLS 1.2, instead of failing is more resilient. If the client accepts SHA1 it will continue with it, while if not, it will fail. If we don't try with SHA1 and send a fatal alert we always fail.

Comment 13 Nikos Mavrogiannopoulos 2016-10-21 15:32:20 UTC
Does this test set includes the case where no signature algorithms is sent?

Comment 14 Hubert Kario 2016-10-21 17:24:59 UTC
(In reply to Nikos Mavrogiannopoulos from comment #12)
> Thanks, nice catch. I have a fix for the MD5-related cases (1):
> https://gitlab.com/gnutls/gnutls/merge_requests/121
> 
> What I am unsure of is (2). If no option is recognized by the server
> attempting to proceed with the default (SHA1) for TLS 1.2, instead of
> failing is more resilient. If the client accepts SHA1 it will continue with
> it, while if not, it will fail. If we don't try with SHA1 and send a fatal
> alert we always fail.

Well, clients that depend on fallback and send garbage in sigalgs wouldn't be able to talk to OpenSSL already, and we know how it ends if you accept signatures you didn't advertise *cough*SLOTH*cough*. Unlike with certificate hashes, I don't think there is good reason to ignore that MUST. Especially given that the RFC explicitly says it is the Right Thing To Doâ„¢ even though it is not an elegant solution.

(In reply to Nikos Mavrogiannopoulos from comment #13)
> Does this test set includes the case where no signature algorithms is sent?

no, I've updated the branch just now - I should have consulted my own checklist[1] :)

 1 - https://github.com/tomato42/tlsfuzzer/wiki/Test-script-checklist

Comment 15 Nikos Mavrogiannopoulos 2016-10-24 13:24:48 UTC
> (In reply to Nikos Mavrogiannopoulos from comment #13)
> > Does this test set includes the case where no signature algorithms is sent?
> 
> no, I've updated the branch just now - I should have consulted my own
> checklist[1] :)
>  1 - https://github.com/tomato42/tlsfuzzer/wiki/Test-script-checklist

Is that the empty sigalgs check? It seems to include the sigalgs extension (I guess it offers no options). I also meant about the case where the sigalgs extension is not included at all (and in that case SHA1 should be expected).

Comment 16 Nikos Mavrogiannopoulos 2016-10-24 13:43:10 UTC
(In reply to Hubert Kario from comment #14)
> (In reply to Nikos Mavrogiannopoulos from comment #12)
> Well, clients that depend on fallback and send garbage in sigalgs wouldn't
> be able to talk to OpenSSL already, and we know how it ends if you accept
> signatures you didn't advertise *cough*SLOTH*cough*. Unlike with certificate
> hashes, I don't think there is good reason to ignore that MUST.

Well that's not precisely the same. Here the server is falling into SHA1 if it has SHA1 enabled by itself (i.e., will not fallback if SHA1 is disabled). Anyway I think it makes sense to switch to more precise behavior. What do the other implementations do btw.?

Comment 18 Hubert Kario 2016-10-25 10:56:54 UTC
(In reply to Nikos Mavrogiannopoulos from comment #15)
> > (In reply to Nikos Mavrogiannopoulos from comment #13)
> > > Does this test set includes the case where no signature algorithms is sent?
> > 
> > no, I've updated the branch just now - I should have consulted my own
> > checklist[1] :)
> >  1 - https://github.com/tomato42/tlsfuzzer/wiki/Test-script-checklist
> 
> Is that the empty sigalgs check? It seems to include the sigalgs extension
> (I guess it offers no options). I also meant about the case where the
> sigalgs extension is not included at all (and in that case SHA1 should be
> expected).

that's tested by test-dhe-rsa-key-exchange-with-bad-messages.py

basically any test case that usees PFS ciphersuite will test that implicitly as in most test cases I don't include extensions, unless testing that particular extension

(In reply to Nikos Mavrogiannopoulos from comment #16)
> (In reply to Hubert Kario from comment #14)
> > (In reply to Nikos Mavrogiannopoulos from comment #12)
> > Well, clients that depend on fallback and send garbage in sigalgs wouldn't
> > be able to talk to OpenSSL already, and we know how it ends if you accept
> > signatures you didn't advertise *cough*SLOTH*cough*. Unlike with certificate
> > hashes, I don't think there is good reason to ignore that MUST.
> 
> What do
> the other implementations do btw.?

NSS has the same bug, OpenSSL correctly aborts, I haven't tested anything else.

Comment 30 errata-xmlrpc 2017-03-21 09:03:32 UTC
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://rhn.redhat.com/errata/RHSA-2017-0574.html


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