From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57758) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgBaI-0007Pc-Lt for qemu-devel@nongnu.org; Mon, 20 Oct 2014 07:57:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgBaC-0006t6-Gy for qemu-devel@nongnu.org; Mon, 20 Oct 2014 07:57:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgBaC-0006t0-A3 for qemu-devel@nongnu.org; Mon, 20 Oct 2014 07:57:04 -0400 Message-ID: <5444F87B.7010708@redhat.com> Date: Mon, 20 Oct 2014 13:56:43 +0200 From: Florian Weimer 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> <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> In-Reply-To: <8738ajq7qo.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] spec, RFC: TLS support for NBD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Stefan Hajnoczi Cc: libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, "Richard W.M. Jones" , qemu-devel@nongnu.org, Hani Benhabiles , nick@bytemark.co.uk, Wouter Verhelst , Paolo Bonzini , Max Reitz 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. -- Florian Weimer / Red Hat Product Security