All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Privoznik <mprivozn@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>, qemu-devel@nongnu.org
Cc: libvir-list@redhat.com, nick@bytemark.co.uk,
	Max Reitz <mreitz@redhat.com>,
	Hani Benhabiles <kroosec@gmail.com>,
	w@uter.be, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [libvirt] NBD TLS support in QEMU
Date: Fri, 05 Sep 2014 08:23:17 +0200	[thread overview]
Message-ID: <540956D5.6080001@redhat.com> (raw)
In-Reply-To: <20140903164417.GA32748@stefanha-thinkpad.redhat.com>

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

  parent reply	other threads:[~2014-09-05  6:23 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03 16:44 [Qemu-devel] NBD TLS support in QEMU Stefan Hajnoczi
2014-09-04 14:19 ` Benoît Canet
2014-09-04 14:34   ` [Qemu-devel] [libvirt] " Daniel P. Berrange
2014-09-04 15:04     ` Benoît Canet
2014-09-04 15:45       ` Stefan Hajnoczi
2014-09-04 15:54     ` John Snow
2014-09-04 22:07   ` [Qemu-devel] " Wouter Verhelst
2014-09-04 22:54     ` Benoît Canet
2014-09-05  8:42       ` Wouter Verhelst
2014-09-05 12:15       ` Stefan Hajnoczi
2014-09-04 22:02 ` Wouter Verhelst
2014-09-05  8:13   ` Daniel P. Berrange
2014-09-05  8:34     ` Wouter Verhelst
2014-09-05 12:21   ` Stefan Hajnoczi
2014-09-05  6:23 ` Michal Privoznik [this message]
2014-09-05  8:10   ` [Qemu-devel] [libvirt] " Daniel P. Berrange
2014-09-05  8:46 ` [Qemu-devel] " Hani Benhabiles
2014-09-05 12:31   ` Stefan Hajnoczi
2014-09-05 13:26   ` Wouter Verhelst
2014-10-01 20:23     ` Wouter Verhelst
2014-10-02 11:00       ` Paolo Bonzini
2014-10-02 13:50         ` Wouter Verhelst
2014-10-08 18:16           ` Wouter Verhelst
2014-10-09 12:42             ` Paolo Bonzini
2014-10-02 11:05       ` Daniel P. Berrange
2014-10-02 11:28         ` Paolo Bonzini
2014-10-17 22:03           ` [Qemu-devel] spec, RFC: TLS support for NBD Wouter Verhelst
2014-10-18  6:33             ` Richard W.M. Jones
2014-10-20  7:58               ` Daniel P. Berrange
2014-10-20  9:56                 ` Stefan Hajnoczi
2014-10-20 11:51                   ` Markus Armbruster
2014-10-20 11:56                     ` Florian Weimer
2014-10-20 12:48                       ` Richard W.M. Jones
2014-10-20 22:10                       ` Wouter Verhelst
2014-10-21  9:35                         ` Daniel P. Berrange
2014-10-21 18:02                           ` Wouter Verhelst
2014-10-20 12:08                     ` Daniel P. Berrange
2014-10-20 21:53                     ` [Qemu-devel] spec, RFC: TLS support for NBDµ Wouter Verhelst
2014-10-21  8:17                       ` Markus Armbruster
2014-10-21 18:30                         ` Wouter Verhelst
2014-10-25 10:43                           ` [Qemu-devel] [Nbd] " Wouter Verhelst
2014-10-30 10:40                             ` Stefan Hajnoczi
2014-10-31 18:15                               ` Wouter Verhelst
2014-11-03 14:30                                 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540956D5.6080001@redhat.com \
    --to=mprivozn@redhat.com \
    --cc=kroosec@gmail.com \
    --cc=libvir-list@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nick@bytemark.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=w@uter.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.