Bug 1326886
Summary: | GnuTLS server rejects connections that do not advertise support for SHA-1 signature algorithms | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Hubert Kario <hkario> |
Component: | gnutls | Assignee: | Nikos Mavrogiannopoulos <nmavrogi> |
Status: | CLOSED ERRATA | QA Contact: | Hubert Kario <hkario> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.8 | CC: | hkario, szidek |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | gnutls-2.12.23-17.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-03-21 09:03:32 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: | |||
Bug Blocks: | 1339222, 1343211 |
Description
Hubert Kario
2016-04-13 16:14:11 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. This protocol requirement was removed in later versions of gnutls to promote interoperability. I've backported that patch, which would fix the described behavior. 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. 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. Does this test set includes the case where no signature algorithms is sent? (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 > (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).
(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.? (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. 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 |