Re: [Qemu-devel] [PATCH v1 RFC 34/34] char: introduce support for TLS encrypted TCP chardev backend

[Kashyap Chamarthy <kchamart@redhat.com>]

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