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