From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgCOR-0001kd-2w for qemu-devel@nongnu.org; Mon, 20 Oct 2014 08:49:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgCOK-0004rh-Cx for qemu-devel@nongnu.org; Mon, 20 Oct 2014 08:48:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgCOK-0004rI-59 for qemu-devel@nongnu.org; Mon, 20 Oct 2014 08:48:52 -0400 Date: Mon, 20 Oct 2014 13:48:26 +0100 From: "Richard W.M. Jones" Message-ID: <20141020124826.GH1349@redhat.com> References: <20140905132608.GB26974@grep.be> <20141001202326.GA2533@grep.be> <20141002110516.GG13032@redhat.com> <542D36E8.2010705@redhat.com> <20141017220323.GC31287@grep.be> <20141018063322.GC1349@redhat.com> <20141020075814.GB19687@redhat.com> <20141020095621.GA28515@stefanha-thinkpad.redhat.com> <8738ajq7qo.fsf@blackfin.pond.sub.org> <5444F87B.7010708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5444F87B.7010708@redhat.com> Subject: Re: [Qemu-devel] spec, RFC: TLS support for NBD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Florian Weimer Cc: Hani Benhabiles , libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, Markus Armbruster , qemu-devel@nongnu.org, Stefan Hajnoczi , nick@bytemark.co.uk, Wouter Verhelst , Paolo Bonzini , Max Reitz 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