qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 RFC 34/34] char: introduce support for TLS en


From: Kashyap Chamarthy
Subject: Re: [Qemu-devel] [PATCH v1 RFC 34/34] char: introduce support for TLS encrypted TCP chardev backend
Date: Wed, 6 May 2015 13:38:28 +0200
User-agent: Mutt/1.5.23.1-rc1 (2014-03-12)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]