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 1498967 - Chardev TCP server does not reset when TLS handshake with client fails
Summary: Chardev TCP server does not reset when TLS handshake with client fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: pagupta
QA Contact: Qianqian Zhu
URL:
Whiteboard:
: 1466597 (view as bug list)
Depends On:
Blocks: 1466597
TreeView+ depends on / blocked
 
Reported: 2017-10-05 16:36 UTC by Daniel Berrangé
Modified: 2018-11-01 11:01 UTC (History)
9 users (show)

Fixed In Version: qemu-kvm-rhev-2.12.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-01 11:01:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Daniel Berrangé 2017-10-05 16:36:15 UTC 
Description of problem:
When QEMU is run with a chardev backed with  a TCP server wth TLS enabled, it fails to cleanup if the TLS handshake with the client fails.

The result is the failed client connection remains open, but no data is read from it, and the client thus thinks it successfully connected.  The server will also not accept any further clients attempting to connect.


Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.9.0-1.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Run QEMU with a serial port with TCP + TLS enabled and verify-peer=yes

/usr/libexec/qemu-kvm \
   -object tls-creds-x509,id=objcharserial1_tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes \
   -chardev socket,id=charserial1,host=127.0.0.1,port=4444,server,nowait,tls-creds=objcharserial1_tls0 \
   -device isa-serial,chardev=charserial1,id=serial1 -
   ...other qemu args....

2. Inside the QEMU guest, run 'cat /dev/ttyS0'  (reply ttyS0 with ttyS1 if TLS was on the 2nd serial porT)

3. Connect to the server with gnutls-cli, providing a CA cert, client cert and client key.
4. Enter 'hello' into gnutls-cli and see that it appears in the guest
5. Ctrl-C to kill gnutls-cli
6. Connect to the server with gnutls-cli, but do *not* provide any client cert to gnutls-cli.
7. The gnutls-cli connection appears to succeed, but it should have failed. Any text typed does not appear in the guest
8. Ctrl-C to kill gnutls-cli
9. Connect to the server with gnutls-cli, providing a CA cert, client cert and client key.
10. Notice that gnutls-cli does not succeeed at connecting at all
Comment 2 Daniel Berrangé 2017-10-05 16:36:46 UTC 
Upstream fix at

https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg01073.html
Comment 3 Daniel Berrangé 2018-06-13 12:25:48 UTC 
Merged in 

commit 9cca7578b45ac5b10c4cdb3dd7e08bb28c766c6d
Author: Daniel P. Berrange <berrange>
Date:   Thu Oct 5 16:50:57 2017 +0100

    char: don't skip client cleanup if 'connected' flag is unset
    

which is part of the QEMU 2.11 release.
Comment 6 Qianqian Zhu 2018-06-20 07:29:04 UTC 
Reproduced on qemu-kvm-rhev-2.9.0-14.el7.x86_64:

Steps:

1. Launch guest, cli:

# /usr/libexec/qemu-kvm    \
-object tls-creds-x509,id=objcharserial1_tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=yes    \
-chardev socket,id=charserial1,host=dhcp-8-165.nay.redhat.com,port=9000,server,nowait,tls-creds=objcharserial1_tls0    \
-device isa-serial,chardev=charserial1,id=serial1  \
-m 2G \
-drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/rhel75-64-virtio.qcow2 \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive_image1,id=virtio-disk0,bootindex=1   \
-device virtio-net-pci,mac=9a:f8:f9:fa:fb:fc,id=idWyOFPn,vectors=4,netdev=idC4NXQZ,bus=pci.0,addr=0x5      \
-netdev tap,id=idC4NXQZ,vhost=on \
-vnc :1 \
-vga cirrus

2. Connect to the server with gnutls-cli, providing a CA cert, client cert and client key:

# gnutls-cli --priority=NORMAL -p9000 --x509cafile=/etc/pki/qemu/ca-cert.pem dhcp-8-165.nay.redhat.com --x509certfile=/etc/pki/qemu/client-cert.pem --x509keyfile=/etc/pki/qemu/client-key.pem

Output:

Processed 1 CA certificate(s).
Processed 1 client X.509 certificates...
Resolving 'dhcp-8-165.nay.redhat.com'...
Connecting to '10.66.8.165:9000'...
(...)
- Successfully sent 1 certificate(s) to server.
(...)
- Handshake was completed

- Simple Client Mode:

[  OK  ] Started Enable periodic update of entitlement certificates..
[  OK  ] Reached target Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems.
(...)
Red Hat Enterprise Linux Server 7.5 (Maipo)
Kernel 3.10.0-862.el7.x86_64 on an x86_64

dhcp-9-48 login:

3. Ctrl+c cancel the gnutls-cli connection.

4. Connect to the server with gnutls-cli, without client cert and client key:

# gnutls-cli --priority=NORMAL -p9000 --x509cafile=/etc/pki/qemu/ca-cert.pem 

Output:

dhcp-8-165.nay.redhat.com
Processed 1 CA certificate(s).
Resolving 'dhcp-8-165.nay.redhat.com'...
Connecting to '10.66.8.165:9000'...

echo c
*** Fatal error: The operation timed out
*** Handshake has failed
GnuTLS error: The operation timed out

5. Connect to the server with gnutls-cli, providing the CA cert, client cert and client key:
# gnutls-cli --priority=NORMAL -p9000 --x509cafile=/etc/pki/qemu/ca-cert.pem dhcp-8-165.nay.redhat.com --x509certfile=/etc/pki/qemu/client-cert.pem --x509keyfile=/etc/pki/qemu/client-key.pem

Result:
After step 5, connection failed:
Processed 1 CA certificate(s).
Processed 1 client X.509 certificates...
Resolving 'dhcp-8-165.nay.redhat.com'...
Connecting to '10.66.8.165:9000'...
*** Fatal error: The operation timed out
*** Handshake has failed
GnuTLS error: The operation timed out



Verified on qemu-kvm-rhev-2.12.0-2.el7.x86_64|kernel-3.10.0-889.el7.x86_64:
Steps same as above.
Result:
Step 4, The connection without client cert and client key is terminated immediately after established:
# gnutls-cli --priority=NORMAL -p9000 --x509cafile=/etc/pki/qemu/ca-cert.pem

- Status: The certificate is trusted. 
(...)
- Handshake was completed

- Simple Client Mode:

*** Fatal error: The TLS connection was non-properly terminated.
*** Server has terminated the connection abnormally.

Step 5, by providing proper cert and key, the connection is established successfully after the handshake fail:
# gnutls-cli --priority=NORMAL -p9000 --x509cafile=/etc/pki/qemu/ca-cert.pem dhcp-8-165.nay.redhat.com --x509certfile=/etc/pki/qemu/client-cert.pem --x509keyfile=/etc/pki/qemu/client-key.pem

Output:
- Options: safe renegotiation,
- Handshake was completed

- Simple Client Mode:

Red Hat Enterprise Linux Server 7.5 (Maipo)
Kernel 3.10.0-862.el7.x86_64 on an x86_64

dhcp-9-48 login:

Successfully login to the guest and it works well.
Comment 7 Qianqian Zhu 2018-06-20 07:33:07 UTC 
Hi Daniel,

Would you help confirm if it is sufficient to verify the bz per the test result in comment 6?

Thanks,
Qianqian
Comment 8 Ademar Reis 2018-07-05 22:41:18 UTC 
*** Bug 1466597 has been marked as a duplicate of this bug. ***
Comment 9 errata-xmlrpc 2018-11-01 11:01:10 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://access.redhat.com/errata/RHBA-2018:3443
Note You need to log in before you can comment on or make changes to this bug.