#Tigervnc tls update
#Tigervnc tls code
#Tigervnc tls series

The output from several diagnostic commands is included below.Īny help in resolving this issue is greatly appreciated. There should not be any firewall active and vncserver and vncpasswd have been executed on the server.

#Tigervnc tls update

This had been previously working, but apparently stopped working after a software update on the Ubuntu server. The TLS session APIs were designed such that they are independent of the underling data transport since while the VNC server always runs over TCP/UNIX sockets, other QEMU backends may wish to run TLS over non-socket based transports.When trying to connect from a Win10 client to a Ubuntu 18.04 server using TigerVNCViewer, I get an error indicating the connection was refused. With the generic TLS credential objects created, the second step was to create a general purpose API for handling the TLS protocol inside QEMU, especially the simplifying the handshake which requires a non-negligible amount of code. These same checks have been done in libvirt for several years now and have been very beneficial in reducing the bugs reports we get related to misconfiguration of TLS. These are all things that the client would check when it connects, so we’re not adding / removing security here, just helping administrators to detect misconfiguration of their TLS certificates as early as possible. It’ll check that the server certificate is actually signed by the CA that is provided and that none of the certs have expired already. Likewise it will check that the server certificate has basic constraints set to indicate usage in a server. For example, it will check that the CA certificate has basic constraints set to indicate usage as a CA, catching problems where people give a server/client cert instead of a CA cert.

#Tigervnc tls code

To help troubleshoot problems, the new x509 credentials code in QEMU will sanity check all certificates it loads prior to using them. Generating correct x509 certificates is something that users often struggle with and when getting it wrong the failures are pretty hard to debug – usually just resulting in an unhelpful “handshake failed” type error message.

To remove the requirement for client certs, the ‘ verify-peer=no‘ option can be given when creating the x509 credentials object.

By default the x509 credentials will require that the client provide a certificate, which is equivalent to the traditional ‘ x509verify‘ option for VNC. The old CLI syntax is still supported, but gets translated internally to create the right TLS credential objects. The VNC server was converted to use the new TLS credential objects for its configuration, so whereas in QEMU 2.4 VNC with TLS would be configured using -vnc 0.0.0.0:0,tls,x509verify=/path/to/certificates/directoryĪs of QEMU 2.5 the preferred approach is to use the new credential objects -object tls-creds-x509,id=tls0.endpoint=server,dir=/path/to/certificates/directory There are now two QOM types tls-creds-anon and tls-creds-x509 that can be created on the command line via QEMU’s -object argument, or in the monitor using the ‘object_add’ command. To achieve this, the new code made use of QEMU’s object model framework (QOM) to define a general TLS credentials interface and then provide implementations for anonymous credentials (totally insecure but needed for back compat with existing QEMU features) and for x509 certificates (the preferred & secure option). So it was necessary to isolate the TLS credential configuration from the TLS session handling code, enabling a single set of TLS credentials to be associated with multiple network servers (they can of course each have a unique set of credentials if desired). The downside of such an approach is that as we add support for TLS to other arguments like -chardev, the user would have to supply the same TLS information in multiple places. With the original patches to support TLS in the VNC server, configuration of the TLS credentials was done as part of the -vnc command line argument.

#Tigervnc tls series

This blog is part 2 of a series I am writing about work I’ve completed over the past few releases to improve QEMU security related features.Īfter the initial consolidation of cryptographic APIs into one area of the QEMU codebase, it was time to move onto step two, which is where things start to directly benefit the users. Posted: April 1st, 2016 | Filed under: Coding Tips, Fedora, libvirt, OpenStack, Security, Virt Tools | Tags: certificates, cryptography, qemu, tls, x509 | 2 Comments »