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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list