1418018 – TLS_DHE_DSS_AES_128_CBC_SHA1 does not work when TLS v1.2 is explicitly disabled

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 1418018 - TLS_DHE_DSS_AES_128_CBC_SHA1 does not work when TLS v1.2 is explicitly disabled

Summary: TLS_DHE_DSS_AES_128_CBC_SHA1 does not work when TLS v1.2 is explicitly disabled

Keywords:
Status:	CLOSED DUPLICATE of bug 1238333
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	gnutls
Sub Component:
Version:	7.3
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Nikos Mavrogiannopoulos
QA Contact:	BaseOS QE Security Team
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2017-01-31 15:46 UTC by Frantisek Sumsal
Modified:	2017-02-21 16:34 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-02-21 16:34:37 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Frantisek Sumsal 2017-01-31 15:46:19 UTC

Description of problem:
gnutls-cli/gnutls-serv fails to establish a connection when TLS_DHE_DSS_AES_128_CBC_SHA1 ciphersuite is used and TLS v1.2 is explicitly disabled. This scenario was tested with NSS, OpenSSL and GNUTLS itself. Even though the reproducer below uses a self-signed certificate, the behavior is exactly the same as with a working (valid) PKI.

Version-Release number of selected component (if applicable):
gnutls-3.3.24-1.el7.x86_64
gnutls-dane-3.3.24-1.el7.x86_64
gnutls-utils-3.3.24-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
# openssl dsaparam 2048 < /dev/random > dsaparam.pem && openssl req -x509 -newkey dsa:dsaparam.pem -keyout key.pem -out cert.pem -nodes -days 3605 -subj "/CN=localhost"
# openssl s_server -www -key key.pem -cert cert.pem -cipher DHE-DSS-AES128-SHA &>server.log &
# #gnutls-serv --x509keyfile key.pem --x509certfile cert.pem --http --port 4433 &>server.log &
# sleep 1
# openssl_pid=$!
# gnutls-cli --port 4433 --insecure --priority NORMAL:-VERS-TLS1.2 localhost < /dev/null
# kill -9 $openssl_pid
# echo "SERVER LOG:"
# cat server.log
# rm -f dsaparam.pem key.pem cert.pem server.log

Actual results:
# OpenSSL server, GNUTLS client --priority NORMAL:-VERS-TLS1.2
Processed 0 CA certificate(s).
Resolving 'localhost'...
Connecting to '::1:4433'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=localhost', issuer `CN=localhost', DSA key 2048 bits, signed using DSA-SHA256, activated `2017-01-31 15:25:02 UTC', expires `2026-12-15 15:25:02 UTC', SHA-1 fingerprint `55d001515fe9fa03fdbaa0b8559c8958ff9fc820'
...
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
*** Fatal error: Public key signature verification has failed.
*** Handshake has failed
GnuTLS error: Public key signature verification has failed.

# GNUTLS server, GNUTLS client --priority NORMAL:-VERS-TLS1.2
Processed 0 CA certificate(s).
Resolving 'localhost'...
Connecting to '::1:4433'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [80]: Internal error
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.
SERVER LOG:
HTTP Server listening on IPv4 0.0.0.0 port 4433...done
HTTP Server listening on IPv6 :: port 4433...done
Error in handshake


Expected results:
# OpenSSL server, GNUTLS client --priority NORMAL:+VERS-TLS1.2
Processed 0 CA certificate(s).
Resolving 'localhost'...
Connecting to '::1:4433'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=localhost', issuer `CN=localhost', DSA key 2048 bits, signed using DSA-SHA256, activated `2017-01-31 15:27:41 UTC', expires `2026-12-15 15:27:41 UTC', SHA-1 fingerprint `1e04f57867ff89966108d07764e5524afca686be'
...
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
- Successfully sent 0 certificate(s) to server.
- Description: (TLS1.2)-(DHE-DSS-1024)-(AES-128-GCM)
- Session ID: 24:7A:2B:72:52:3E:EB:5E:FE:31:CA:D0:0F:BE:69:31:E7:DA:61:72:60:9A:D8:C0:38:8C:79:8A
:3F:D4:80:48
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 320 bits
 - Peer's public key: 1023 bits
- Version: TLS1.2
- Key Exchange: DHE-DSS
- Server Signature: DSA-SHA256
- Cipher: AES-128-GCM
- MAC: AEAD
- Compression: NULL
- Options: safe renegotiation,
- Handshake was completed

- Simple Client Mode:

Comment 2 Nikos Mavrogiannopoulos 2017-02-21 12:49:16 UTC

Is that bug report on RHEL-7 or from Fedora? In Fedora DSA ciphersuites are disabled by default. In RHEL-7 it should work.

Comment 3 Frantisek Sumsal 2017-02-21 13:02:11 UTC

This issue in on RHEL 7:

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.3 (Maipo)
# rpm -qa | grep gnutls
gnutls-3.3.24-1.el7.x86_64
gnutls-dane-3.3.24-1.el7.x86_64
gnutls-utils-3.3.24-1.el7.x86_64

The same behavior can be seen on the latest compose of RHEL 7.4 as well:

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.4 Beta (Maipo)
# rpm -qa | grep gnutls
gnutls-dane-3.3.26-2.el7.x86_64
gnutls-utils-3.3.26-2.el7.x86_64
gnutls-3.3.26-2.el7.x86_64

Comment 4 Nikos Mavrogiannopoulos 2017-02-21 13:13:43 UTC

You are right. This is correct. The same version of gnutls when compiled in Fedora25 works right. It must be related to nettle version in RHEL7.3.

Comment 5 Nikos Mavrogiannopoulos 2017-02-21 13:30:29 UTC

Your test is with DSA-2048 parameters. Such parameters are not defined to be used for TLS 1.x, x<2. Indeed the error can be confusing, but it is an unsupported use-case.

Comment 6 Nikos Mavrogiannopoulos 2017-02-21 13:32:21 UTC

For the record, it can still be fixed by removing an unnecessary check in _dsa_verify() in nettle (checks for match of digest with size of Q which is not the case in the example above).

Comment 7 Tomas Mraz 2017-02-21 15:52:11 UTC

Is this a regression? If not I would say we do not really care.

Comment 8 Alicja Kario 2017-02-21 16:34:37 UTC


*** This bug has been marked as a duplicate of bug 1238333 ***

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