Red Hat Bugzilla – Bug 1328205
gnutls-cli won't send certificates that don't match hashes in Certificate Request
Last modified: 2017-03-21 05:03:47 EDT
Description of problem: If the server is asking for just some hashes in the Certificate Request message, client will not try sending the Certificate anyway. Moreover, if the certificate is signed with a strong hash (e.g. SHA-512), the connection is not successful even if server is asking for SHA-512. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Start a server asking for just sha-384 signatures in Certificate Request 2. Try connecting to it using gnutls-cli with a sha-256 signed certificate 1. Start a server asking for just sha-512 signatures in Certificate Request 2. Try connecting to it using gnutls-cli with a sha-512 signed certificate Actual results: - Could not find a suitable certificate to send to server *** Fatal error: GnuTLS internal error. in sha-512 case: *** Fatal error: The signature algorithm is not supported. Expected results: - Handshake was completed Additional info: While the behaviour in which the client doesn't sent certificates not matching signatures requested by server matches the RFC 5246, the general consensus of the IETF TLS WG is that this was not a good idea. This requirement was ultimately removed in TLSv1.3. Moreover, it is not exhibited by newer GnuTLS (on RHEL-7 or Fedora 22).
This bug is tricky to be solved and most probably won't. If I remember correctly, versions of TLS prior to 1.2 could use a running hash (e.g., SHA1) throughout the handshake, and will use the output of this hash for any signatures that need to be generated. Starting with TLS 1.2 the hash is negotiated, but a client will not know the hash to be used for client-cert signatures up until the point the server asks for one. At this point this gnutls client has two hashes running sha1 + sha256. Thus if the server asks for anything else it wouldn't work. As such the preferred action is to mark the gnutls client as capable of handling sha1+sha256 hashes only, and treat it as a known bug. (Note that it doesn't make sense for the client to restrict its supported signature hashes to sha1+sha256 only, because the client can handle more signature hashes when the signature come from the server side).
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
(In reply to Nikos Mavrogiannopoulos from comment #1) > This bug is tricky to be solved and most probably won't. If I remember > correctly, versions of TLS prior to 1.2 could use a running hash (e.g., > SHA1) throughout the handshake, and will use the output of this hash for any > signatures that need to be generated. Starting with TLS 1.2 the hash is > negotiated, but a client will not know the hash to be used for client-cert > signatures up until the point the server asks for one. At this point this > gnutls client has two hashes running sha1 + sha256. Thus if the server asks > for anything else it wouldn't work. > > As such the preferred action is to mark the gnutls client as capable of > handling sha1+sha256 hashes only, and treat it as a known bug. > (Note that it doesn't make sense for the client to restrict its supported > signature hashes to sha1+sha256 only, because the client can handle more > signature hashes when the signature come from the server side). Then it means that it's the exact same bug as the one we have in NSS, bug 1238369, with the same interoperability issues: Windows clients with certificates signed with anything but SHA-256 or SHA-1 will not work.
Given the scope of this change, rsyslog (or cups), and the fact that there is no web server using gnutls in rhel, I don't that this is any serious limitation.
If we don't add support for SHA-384 and SHA-512 signatures in Certificate Verify, the second issue still remains: > - Could not find a suitable certificate to send to server > *** Fatal error: GnuTLS internal error. In other words, if client has only certificate signed with SHA-384 and the server is asking only for SHA-256 or SHA-1 signatures, it should still send the certificate to server but sign the Certificate Verify with SHA-256.
That restricted scope can be addressed in RHEL-6.9. Adding high priority.
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