From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpeFJ-0006za-Vc for qemu-devel@nongnu.org; Tue, 05 May 2015 10:55:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpeFE-0003zK-0Q for qemu-devel@nongnu.org; Tue, 05 May 2015 10:54:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpeFD-0003zB-On for qemu-devel@nongnu.org; Tue, 05 May 2015 10:54:47 -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 378FE247 for ; Tue, 5 May 2015 14:54:47 +0000 (UTC) Date: Tue, 5 May 2015 16:54:44 +0200 From: Kashyap Chamarthy Message-ID: <20150505145444.GH30897@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150505134951.GC32600@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 Tue, May 05, 2015 at 02:49:51PM +0100, Daniel P. Berrange wrote: > On Mon, May 04, 2015 at 10:07:15PM +0200, Kashyap Chamarthy wrote: > > On Fri, Apr 17, 2015 at 03:22:37PM +0100, Daniel P. Berrange wrote: > > > This integrates support for QIOChannelTLS object in the TCP > > > chardev backend. If the 'tls-cred=NAME' option is passed with > > > the '-chardev tcp' argument, then it will setup the chardev > > > such that the client is required to establish a TLS handshake > > > when connecting. The 'acl' option will further enable the > > > creation of a 'char.$ID.tlspeername' ACL which will be used > > > to validate the client x509 certificate, if provided. > > > > > > A complete invokation to run QEMU as the server for a TLS > > > encrypted serial dev might be > > > > > > $ qemu-system-x86_64 \ > > > -nodefconfig -nodefaults -device sga -display none \ > > > -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-cred=tls0,server \ > > > -device isa-serial,chardev=s0 \ > > > -object qcrypto-tls-cred,id=tls0,credtype=x509,\ > > > endpoint=server,dir=/home/berrange/security/qemutls,verify-peer=off > > > > > > To test with the gnutls-cli tool as the client: > > > > > > $ gnutls-cli --priority=NORMAL -p 9000 \ > > > --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ > > > 127.0.0.1 > > > > > > If QEMU was told to use 'anon' credential type, then use the > > > priority string 'NOMAL:+ANON-DH' with gnutls-cli > > > > > > Alternatively, if setting up a chardev to operate as a client, > > > then the TLS credentials registered must be for the client > > > endpoint. First a TLS server must be setup, which can be done > > > with the gnutls-serv tool > > > > > > $ gnutls-serv --priority=NORMAL -p 9000 \ > > > --x509cafile=/home/berrange/security/qemutls/ca-cert.pem \ > > > --x509certfile=/home/berrange/security/qemutls/server-cert.pem \ > > > --x509keyfile=/home/berrange/security/qemutls/server-key.pem > > > > > > Then QEMU can connect with > > > > > > $ qemu-system-x86_64 \ > > > -nodefconfig -nodefaults -device sga -display none \ > > > -chardev socket,id=s0,host=127.0.0.1,port=9000,tls-cred=tls0 \ > > > -device isa-serial,chardev=s0 \ > > > -object qcrypto-tls-cred,id=tls0,credtype=x509,\ > > > endpoint=client,dir=/home/berrange/security/qemutls > > > > I've applied your 'qemu-io-channel-7' branch locally, compiled QEMU and > > began to play around. > > > > $ git describe > > v2.3.0-rc3-42-g5878696 > > > > When running QEMU either as server or as client, I notice this error > > (further below are the details of how I tested): > > > > [. . .] > > qemu-system-x86_64: -object qcrypto-tls-cred,id=tls0,credtype=x509,: > > invalid object type: qcrypto-tls-cred > > Typo in my commit message - it should end in '-creds' not '-cred' for > the object type. Yep, that fixed it. I should have looked deeper -- your example in include/crypto/tlscreds.h has the correct syntax and also includes a QMP variant. Just to note, there seems to be three instances of this typo in qemu-options.hx (found via `git grep qcrypto-tls-cred`). 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) -- /kashyap