[Spice-devel] [spice-gtk v2 0/3] ssl: Add support for OpenSSL 1.1.0
Fabian Grünbichler
f.gruenbichler at proxmox.com
Wed Jan 11 14:05:45 UTC 2017
On Wed, Jan 11, 2017 at 01:00:09PM +0100, Christophe Fergeau wrote:
> Hey Fabian,
>
> On Wed, Jan 11, 2017 at 12:21:35PM +0100, Fabian Grünbichler wrote:
> > On Wed, Jan 11, 2017 at 10:50:30AM +0100, Christophe Fergeau wrote:
> > > Sebastian sent these patches privately a while ago, I've run some tests on them
> > > and helped split them. They add support for OpenSSL 1.1.0 which makes some of the
> > > structures we were directly accessing private. This also keeps support with older
> > > OpenSSL releases by adding some compat helpers.
> > >
> > > These patches have been tested against a RHEV instance, and against manually configured
> > > QEMU+SPICE+TLS.
> >
> > Might be our (unusual) setup, but this and the previous version of this
> > patch included in Debian Sid seem to break connecting to Spice servers
> > listening only on TLS.
>
> Thanks for the report!
>
> >
> > starting a qemu VM with
> >
> > -chardev spicevmc,id=charchannel0,name=vdagent \
> > -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \
> > -spice tls-port=5901,addr=AAA.BBB.CCC.DDD,disable-ticketing,x509-dir=/etc/pki/libvirt-spice,image-compression=off,seamless-migration=on
> >
> > and QXL makes qemu listen on port 5901 with TLS only (tested with qemu
> > and libvirt from Debian Sid, although we noticed the original problem
> > when using Proxmox VE 4.4 on the server side, which is based on Debian
> > Jessie and uses a custom Qemu).
> >
> > connecting using spicy on Debian Sid (with appropriately set
> > ~/.spicec/spice_truststore.pem and correctly generated self-signed
> > certificates) doesn't work:
> >
> > # dpkg --list | grep spice
> > ii gir1.2-spice-client-glib-2.0 0.33-3.2 amd64 GObject for communicating with Spice servers (GObject-Introspection)
> > ii gir1.2-spice-client-gtk-3.0 0.33-3.2 amd64 GTK3 widget for SPICE clients (GObject-Introspection)
> > ii libspice-client-glib-2.0-8:amd64 0.33-3.2 amd64 GObject for communicating with Spice servers (runtime library)
> > ii libspice-client-gtk-3.0-5:amd64 0.33-3.2 amd64 GTK3 widget for SPICE clients (runtime library)
> > ii libspice-protocol-dev 0.12.12-1 all SPICE protocol headers
> > ii libspice-server1:amd64 0.12.8-2 amd64 Implements the server side of the SPICE protocol
> > ii spice-client-glib-usb-acl-helper 0.33-3.2 amd64 Helper tool to validate usb ACLs
> > ii spice-client-gtk 0.33-3.2 amd64 Simple clients for interacting with SPICE servers
> >
> > $ spicy -h AAA.BBB.CCC.DDD -s 5901 --spice-debug &> spicy-broken.log
> >
> > see attachment for full log, excerpt:
> >
> > GSpice-WARNING **: main-1:0: SSL_connect: error:00000001:lib(0):func(0):reason(1)
> > GSpice-Message: main channel: failed to connect
> >
> > the qemu process logs the following error message:
> > (/usr/bin/qemu-system-x86_64:7758): Spice-Warning **: reds_stream.c:379:reds_stream_ssl_accept: SSL_accept failed, error=5
> >
> > downgrading the spice client packages to Stretch makes everything work
> > again:
> >
> > # apt-get install gir1.2-spice-client-glib-2.0=0.33-3 gir1.2-spice-client-gtk-3.0=0.33-3 libspice-client-glib-2.0-8=0.33-3 libspice-client-gtk-3.0-5=0.33-3 spice-client-glib-usb-acl-helper
> > =0.33-3 spice-client-gtk=0.33-3
> >
> > $ spicy -h AAA.BBB.CCC.DDD -s 5901 --spice-debug &> spicy-works.log
> >
> > also attached.
> >
> > a TLS connection attempt with
> >
> > $ openssl -debug -connect AAA.BBB.CCC.DDD:5901
> >
> > shows that ECDHE-RSA-AES256-GCM-SHA384 is negotiated, but I did not
> > verify whether this is also true for the connection made by spicy.
> >
> > any idea what's going amiss here?
> >
>
> I've tried to reproduce this with the latest version of the patches. I
> setup a TLS-only SPICE VM on a RHEL6 host (using libvirt), and connected to it
> with spicy, both with --spice-ca-file, and with a
> .spicec/spice_truststore.pem file, and in both cases this worked fine.
> Is sid using openssl 1.1.0 or older? I've tested with
> openssl-1.0.2j-3.fc25.x86_64
AFAIK the situation regarding OpenSSL in Sid/Stretch is rather
complicated - upstream / the OpenSSL maintainers / .. are pushing for a
transition to 1.1.0 (currently 1.1.0c), but there was quite a backlash
from various maintainers because of the ABI breakage and not-yet-updated
upstreams. Now there are two -dev packages, libssl-dev (previously
1.0.X, now 1.1.0c) and libssl1.0-dev and a boatload of bug reports and
patches for various packages to transition to 1.1.0 in a backwards
compatible way. Whether the move to 1.1.0 for Stretch will really happen
was unclear the last time I checked, but that was some time in December
(or maybe even November?). You can check the debian-devel archives if
you are in the mood for reading long back and forth threads ;)
Anyhow, the spice client packages in Debian Stretch are still compiled
against libssl1.0-dev (which is 1.0.2j-4), the ones in Debian Sid are
compiled against libssl-dev (which is 1.1.0c-2).
>
> I assume you are getting the same results if you use --spice-ca-file
> instead of .spicec/spice_truststore.pem?
> By any chance, would it be possible for you to try the latest version of
> these patches rather than what they have in debian, as they are a bit
> different at this point?
>
Compiling the current spice-gtk master with v2 of this patch set
- against libssl-dev on Sid works as expected
- against libssl1.0-dev on Sid works as expected (which matches with
your result)
Compiling the current spice-gtk master without the patch set
- against libssl-dev on Sid does not work (hence the patch set ;))
- against libssl1.0-dev on Sid works as expected
Replacing the old patch in Debian Sid's source package with v2 of this
patch set and rebuilding also works as expected. I'll open a bug report
on the Debian side to get the current patch set included in the Debian
package, unless there are any objections (or an upcoming v3) from your
side?
Thanks for the quick response (and sorry for the noise!)
More information about the Spice-devel
mailing list