Stefan Hajnoczi <stefanha@xxxxxxxxxx> writes: > On Mon, Oct 20, 2014 at 08:58:14AM +0100, Daniel P. Berrange wrote: >> On Sat, Oct 18, 2014 at 07:33:22AM +0100, Richard W.M. Jones wrote: >> > On Sat, Oct 18, 2014 at 12:03:23AM +0200, Wouter Verhelst wrote: >> > > Hi all, >> > > >> > > (added rjones from nbdkit fame -- hi there) >> > >> > [I'm happy to implement whatever you come up with, but I've added >> > Florian Weimer to CC who is part of Red Hat's product security group] >> > >> > > So I think the following would make sense to allow TLS in NBD. >> > > >> > > This would extend the newstyle negotiation by adding two options (i.e., >> > > client requests), one server reply, and one server error as well as >> > > extend one existing reply, in the following manner: >> > > >> > > - The two new commands are NBD_OPT_PEEK_EXPORT and NBD_OPT_STARTTLS. The >> > > former would be used to verify if the server will do TLS for a given >> > > export: >> > > >> > > C: NBD_OPT_PEEK_EXPORT >> > > S: NBD_REP_SERVER, with an extra field after the export name >> > > containing flags that describe the export (R/O vs R/W state, >> > > whether TLS is allowed and/or required). >> >> IMHO the server should never provide *any* information about the exported >> volume(s) until the TLS layer has been fully setup. ie we shouldn't only >> think about the actual block data transfers, we should protect the entire >> NBD protocol even metadata related operations. > > This makes sense. Seconded. > TLS is about the transport, not about a particular NBD export. The only > thing that should be communicated is STARTTLS. 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? See also https://www.agwa.name/blog/post/starttls_considered_harmful -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list