From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypxeu-0008Sx-RN for qemu-devel@nongnu.org; Wed, 06 May 2015 07:38:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ypxep-0008Is-MR for qemu-devel@nongnu.org; Wed, 06 May 2015 07:38:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ypxep-0008Io-F6 for qemu-devel@nongnu.org; Wed, 06 May 2015 07:38:31 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 0DE328E710 for ; Wed, 6 May 2015 11:38:31 +0000 (UTC) Date: Wed, 6 May 2015 13:38:28 +0200 From: Kashyap Chamarthy Message-ID: <20150506113828.GJ30897@tesla.redhat.com> References: <1429280557-8887-1-git-send-email-berrange@redhat.com> <1429280557-8887-35-git-send-email-berrange@redhat.com> <20150504200715.GF11726@tesla.redhat.com> <20150505134951.GC32600@redhat.com> <20150505145444.GH30897@tesla.redhat.com> <20150506083406.GA6856@tesla.redhat.com> <20150506101822.GD7492@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150506101822.GD7492@redhat.com> Subject: Re: [Qemu-devel] [PATCH v1 RFC 34/34] char: introduce support for TLS encrypted TCP chardev backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Paolo Bonzini , qemu-devel@nongnu.org, Stefan Hajnoczi , Gerd Hoffmann On Wed, May 06, 2015 at 11:18:23AM +0100, Daniel P. Berrange wrote: > On Wed, May 06, 2015 at 10:34:06AM +0200, Kashyap Chamarthy wrote: > > On Tue, May 05, 2015 at 04:54:44PM +0200, Kashyap Chamarthy wrote: > > > > [. . .] > > > > > While running QEMU as TLS server, the TLS handshake completes > > > successfully when connected via `gnutls-cli`. > > > > > > However, when using QEMU as client to connect to an existing GnuTLS > > > server, I notice a segmentation fault: > > > > > > $ /home/kashyapc/build/tls-qemu/x86_64-softmmu/qemu-system-x86_64 \ > > > -nodefconfig -nodefaults -device sga -display none \ > > > -chardev socket,id=s0,host=localhost,port=9000,tls-cred=tls0 \ > > > -device isa-serial,chardev=s0 \ > > > -object qcrypto-tls-creds,id=tls0,credtype=x509,endpoint=client,dir=/export/security/gnutls > > > Segmentation fault (core dumped) > > > > Some debugging with `gdb` below. > > > > QEMU was built with: > > > > ./configure --target-list=x86_64-softmmu --enable-debug > > make -j4 > > > > Stack traces: > > > > $ gdb /home/kashyapc/build/tls-qemu/x86_64-softmmu/qemu-system-x86_64 > > > #2 0x00007ffff1c6b3d9 in gnutls_certificate_set_x509_key_file2 () at /lib64/libgnutls.so.28 > > #3 0x00005555559aba85 in qcrypto_tls_creds_load_x509 (creds=0x55555639ac60, errp=0x7fffffffd8d8) at /home/kashyapc/tinker-space/qemu/crypto/tlscreds.c:728 > > cacert = 0x55555639a8c0 "/export/security/gnutls/ca-cert.pem" > > cacrl = 0x0 > > cert = 0x0 > > key = 0x0 > > dhparams = 0x0 > > ret = 1 > > rv = -1 > > Ah, with QEMU running in client mode, the client cert + key are > optional. In this case you've not provided them (cert & key are 0x0 ie > NULL). Yep, I generated a client-key.pem, client-cert.pem and placed them in the same gnutls directory where the ca* and server* files are located. Indeed the TLS handshake completes succesfully (tested with the same QEMU CLI as above placed in a script): $ ./chardev-backend-qemu-as-tls-client.sh Handshake still running 2 Handshake still running 2 Handshake compelte session=0x7f8bdda6f4c0 On the GnuTLS server: [. . .] * Accepted connection from IPv4 127.0.0.1 port 51353 on Wed May 6 13:19:10 2015 - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1) [. . .] - Server has requested a certificate. - Certificate type: X.509 - Got a certificate list of 1 certificates. [. . .] - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Client Signature: RSA-SHA256 - Compression: NULL - Options: safe renegotiation, - Channel binding 'tls-unique': 7f4ae1e0dc02dbad602a9c27 > We are then mistakenly calling gnutls_certificate_set_x509_key_file2 - > if I simply skip that I'll avoid the crash. Thanks for testing this - > I'll add a test case to validate this scenario too -- /kashyap