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!) _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel