From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44419)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XZe7k-0002MG-BX
	for qemu-devel@nongnu.org; Thu, 02 Oct 2014 07:00:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XZe7e-00027E-7Y
	for qemu-devel@nongnu.org; Thu, 02 Oct 2014 07:00:40 -0400
Received: from mx1.redhat.com ([209.132.183.28]:16109)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1XZe7d-000276-Q8
	for qemu-devel@nongnu.org; Thu, 02 Oct 2014 07:00:34 -0400
Message-ID: <542D3034.2050700@redhat.com>
Date: Thu, 02 Oct 2014 13:00:04 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <20140903164417.GA32748@stefanha-thinkpad.redhat.com>
	<20140905084618.GA3720@Inspiron-3521>
	<20140905132608.GB26974@grep.be> <20141001202326.GA2533@grep.be>
In-Reply-To: <20141001202326.GA2533@grep.be>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] NBD TLS support in QEMU
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Wouter Verhelst <w@uter.be>, Hani Benhabiles <kroosec@gmail.com>
Cc: libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, nick@bytemark.co.uk

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.

Paolo