qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [libvirt] NBD TLS support in QEMU


From: Michal Privoznik
Subject: Re: [Qemu-devel] [libvirt] NBD TLS support in QEMU
Date: Fri, 05 Sep 2014 08:23:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 03.09.2014 18:44, Stefan Hajnoczi wrote:
Hi,
QEMU offers both NBD client and server functionality.  The NBD protocol
runs unencrypted, which is a problem when the client and server
communicate over an untrusted network.

This is not problem for NBD only, but for the rest of data that qemu sends over network, i.e. migration stream, VNC/SPICE, ...


The particular use case that prompted this mail is storage migration in
OpenStack.  The goal is to encrypt the NBD connection between source and
destination hosts during storage migration.

I think we can integrate TLS into the NBD protocol as an optional flag.
A quick web search does not reveal existing open source SSL/TLS NBD
implementations.  I do see a VMware NBDSSL protocol but there is no
specification so I guess it is proprietary.

In case of libvirt, we have so called tunnelled migration (both spelled & misspelled :P) in which libvirt opens a local ports on both src & dst side and then sets up secured forwarding pipe to the other side. Or a insecured one if user wishes so. The only problem is that when I adapted libvirt for NBD, I intentionally forbade NBD in tunnelled migration as it requires one more data stream for which libvirt migration protocol is not ready yet. Having saidy that, I feel that libvirt is the show stopper here, not QEMU.

I'm not saying that I'm against this. I've heard rumors that not everybody out there uses libvirt and thus they might appreciate this ability.


The NBD protocol starts with a negotiation phase.  This would be the
appropriate place to indicate that TLS will be used.  After client and
server complete TLS setup the connection can continue as normal.

Yep, that's how most of the secured protocols run. Somebody mentions STARTTLS for which I vote as well.


Besides QEMU, the userspace NBD tools (http://nbd.sf.net/) can also be
extended to support TLS.  In this case the kernel needs a localhost
socket and userspace handles TLS.

Michal



reply via email to

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