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:


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@redhat.com>
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.