Re: [Qemu-devel] spec, RFC: TLS support for NBD

["Richard W.M. Jones" <rjones@redhat.com>]

On Mon, Oct 20, 2014 at 01:56:43PM +0200, Florian Weimer wrote:
> On 10/20/2014 01:51 PM, Markus Armbruster wrote:
> >Furthermore, STARTTLS is vulnerable to active attacks: if you can get
> >between the peers, you can make them fall back to unencrypted silently.
> >How do you plan to guard against that?
> 
> The usual way to deal with this is to use different syntax for
> TLS-enabled and non-TLS addresses (e.g., https:// and http://).
> With a TLS address, the client must enforce that only TLS-enabled
> connections are possible.  STARTTLS isn't the problem here, it's
> just an accident of history that many STARTTLS client
> implementations do not require a TLS handshake before proceeding.
> 
> I cannot comment on whether the proposed STARTTLS command is at the
> correct stage of the NBD protocol.  If there is a protocol
> description for NBD, I can have a look.

Two actually :-)  Both are covered here:

http://sourceforge.net/p/nbd/code/ci/master/tree/doc/proto.txt

I believe that the proposed changes only cover the new style
protocol.

There's no common syntax for nbd URLs that I'm aware of.  At least,
both qemu & guestfish have nbd:... strings that they can parse, but
both have a completely different syntax.  But we could still have a
client-side indication (flag or nbds:..) to say that we want to force
TLS.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top