From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xbylg-0001jx-Ms for qemu-devel@nongnu.org; Wed, 08 Oct 2014 17:27:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbylZ-0002qq-6f for qemu-devel@nongnu.org; Wed, 08 Oct 2014 17:27:32 -0400 Received: from barbershop.grep.be ([89.106.240.122]:35145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbylZ-0002qa-0L for qemu-devel@nongnu.org; Wed, 08 Oct 2014 17:27:25 -0400 Date: Wed, 8 Oct 2014 20:16:10 +0200 From: Wouter Verhelst Message-ID: <20141008181610.GA27382@grep.be> References: <20140903164417.GA32748@stefanha-thinkpad.redhat.com> <20140905084618.GA3720@Inspiron-3521> <20140905132608.GB26974@grep.be> <20141001202326.GA2533@grep.be> <542D3034.2050700@redhat.com> <20141002135057.GA20677@grep.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002135057.GA20677@grep.be> Subject: Re: [Qemu-devel] NBD TLS support in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Hani Benhabiles , libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , nick@bytemark.co.uk On Thu, Oct 02, 2014 at 03:50:57PM +0200, Wouter Verhelst wrote: > On Thu, Oct 02, 2014 at 01:00:04PM +0200, Paolo Bonzini wrote: > > Il 01/10/2014 22:23, Wouter Verhelst ha scritto: > > > Hi, > > > > > > On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote: > > >> Tunneling the entire protocol inside an SSL connection doesn't fix that; > > >> if an attacker is able to hijack your TCP connections and change flags, > > >> then this attacker is also able to hijack your TCP connection and > > >> redirect it to a decrypting/encrypting proxy. > > >> > > >> I agree that preventing a possible SSL downgrade attack (and other forms > > >> of MITM) should be high on the priority list, but "tunnel the whole > > >> thing in SSL" doesn't do that. > > > > > > So, having given this some thought, I wanted to come up with a spec just > > > so that we had something we could all agree on. As part of that, I had a > > > look at qemu-nbd, and noticed that it uses the "oldstyle" handshake > > > protocol (on port 10809 by default -- ew, please don't do that). > > > > Can you use new-style handshake with a single unnamed export? Export > > names are a useless complication for qemu-nbd. > > Not currently, but I don't think you need that. You could have a default > name, which would be used if no name was otherwise specified. It's not > much of a stretch to make that name part of the protocol spec, either. So. I think this makes sense, and as such changed the proto.txt file as follows: diff --git a/doc/proto.txt b/doc/proto.txt index e0a4fb1..990d012 100644 --- a/doc/proto.txt +++ b/doc/proto.txt @@ -242,10 +242,13 @@ Option types * NBD_OPT_EXPORT_NAME (1) Choose the export which the client would like to use, and end option haggling. Data: name of the export, free-form UTF8 text (subject to limitations by server implementation). If the chosen export does not exist, the server closes the connection. + A special, "empty", name (i.e., the length field is zero and no name + is specified), is reserved for a "default" export, to be used in cases + where explicitly specifying an export name makes no sense. * NBD_OPT_ABORT (2) Abort negotiation and close the connection. Optional. * NBD_OPT_LIST (3) That is, specify an empty name to specify a default. Thoughts? -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26