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