From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZeZL-0000OS-Hy for qemu-devel@nongnu.org; Thu, 02 Oct 2014 07:29:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZeZF-00058l-9h for qemu-devel@nongnu.org; Thu, 02 Oct 2014 07:29:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZeZF-00058Y-2K for qemu-devel@nongnu.org; Thu, 02 Oct 2014 07:29:05 -0400 Message-ID: <542D36E8.2010705@redhat.com> Date: Thu, 02 Oct 2014 13:28:40 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20140903164417.GA32748@stefanha-thinkpad.redhat.com> <20140905084618.GA3720@Inspiron-3521> <20140905132608.GB26974@grep.be> <20141001202326.GA2533@grep.be> <20141002110516.GG13032@redhat.com> In-Reply-To: <20141002110516.GG13032@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] NBD TLS support in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Wouter Verhelst 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 Il 02/10/2014 13:05, Daniel P. Berrange ha scritto: > On Wed, Oct 01, 2014 at 10:23:26PM +0200, Wouter Verhelst wrote: >> 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). >> >> I had to change the protocol incompatibly a few years back, because the >> oldstyle protocol is broken by design; in the oldstyle negotiation >> protocol, the server dumps all information it has on the export to the >> client, and then moves on to the data negotiation phase, without waiting >> for any reply from the client. This means the oldstyle protocol can't be >> used for any sort of negotiation[1]. >> >> As such, I strongly suggest that qemu-nbd move to the newstyle protocol. > > Even if we added support for the newstyle protocol I don't see us being > able to drop the oldstyle protocol. NBD is used during migration of block > storage, and we need to be able to migrate from old QEMU to new QEMU and > vica-verca, so can't just switch protocol in a new QEMU without retaining > a way to use the old protocol. For that you don't use qemu-nbd, we use the NBD server that is embedded in the QEMU executable. That one shares almost all the code with qemu-nbd but, because we are exporting multiple disks over a single port, ends up using the new-style protocol. qemu-nbd uses the old-style protocol only because it has a single, unnamed export. QEMU's NBD client will use the old-style protocol if given URLs like nbd://HOST:PORT/, and the new-style protocol for nbd://HOST:PORT/NAME. Paolo