From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYzIj-0005Q8-0w for qemu-devel@nongnu.org; Mon, 07 Sep 2015 12:29:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYzIh-0004dw-Cu for qemu-devel@nongnu.org; Mon, 07 Sep 2015 12:29:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYzIh-0004dh-8V for qemu-devel@nongnu.org; Mon, 07 Sep 2015 12:29:47 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 0B2BF2D8B64 for ; Mon, 7 Sep 2015 16:29:47 +0000 (UTC) Date: Mon, 7 Sep 2015 17:29:43 +0100 From: "Daniel P. Berrange" Message-ID: <20150907162943.GW29882@redhat.com> References: <1441294768-8712-1-git-send-email-berrange@redhat.com> <1441294768-8712-46-git-send-email-berrange@redhat.com> <20150907162301.GI2337@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150907162301.GI2337@work-vm> Subject: Re: [Qemu-devel] [PATCH FYI 45/46] migration: support TLS encryption with TCP migration backend Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Juan Quintela , qemu-devel@nongnu.org, Gerd Hoffmann , Amit Shah , Paolo Bonzini On Mon, Sep 07, 2015 at 05:23:01PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berrange@redhat.com) wrote: > > This extends the TCP migration backend so that it can make use > > of QIOChannelTLS to provide transparent TLS encryption. To > > trigger enablement the URI on the incoming and outgoing sides > > should have 'tls-creds=ID' appended, eg > > > > tcp:$HOST:$PORT,tls-creds=ID > > What makes this tcp specifc? Would it work on any bidirectional > transport? TLS is capable of working on any bi-directional transport. When using x509 certificates with TLS though, the client would typically validate the server identity by comparing the hostname it connected to, with the hostname encoded in the server's x509 certificate. So if we want to enable use of TLS over a transport that isn't TCP, we'd need to figure out the policy around x509 certificate validation. This isn't neccessarily hard, but it would need someone to describe the usage scenario, so we can figure out what makes sense from the security POV. Since I've not heard of anyone asking for TLS support on non-TCP transports, I figured it was fine to only plumb it into tcp: for migration for now and avoid these questions. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|