From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgKtn-0008OR-JL for qemu-devel@nongnu.org; Mon, 20 Oct 2014 17:54:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgKtg-0002kO-RD for qemu-devel@nongnu.org; Mon, 20 Oct 2014 17:53:55 -0400 Received: from barbershop.grep.be ([89.106.240.122]:60575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgKtg-0002jU-Is for qemu-devel@nongnu.org; Mon, 20 Oct 2014 17:53:48 -0400 Date: Mon, 20 Oct 2014 23:53:24 +0200 From: Wouter Verhelst Message-ID: <20141020215324.GA19214@grep.be> References: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <8738ajq7qo.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] =?iso-8859-1?q?spec=2C_RFC=3A_TLS_support_for_NBD=B5?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Florian Weimer , Hani Benhabiles , libvir-list@redhat.com, mprivozn@redhat.com, nbd-general@lists.sf.net, "Richard W.M. Jones" , qemu-devel@nongnu.org, Stefan Hajnoczi , nick@bytemark.co.uk, Paolo Bonzini , Max Reitz --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2014 at 01:51:43PM +0200, Markus Armbruster wrote: > Stefan Hajnoczi writes: >=20 > > On Mon, Oct 20, 2014 at 08:58:14AM +0100, Daniel P. Berrange wrote: > >> On Sat, Oct 18, 2014 at 07:33:22AM +0100, Richard W.M. Jones wrote: > >> > On Sat, Oct 18, 2014 at 12:03:23AM +0200, Wouter Verhelst wrote: > >> > > Hi all, > >> > >=20 > >> > > (added rjones from nbdkit fame -- hi there) > >> >=20 > >> > [I'm happy to implement whatever you come up with, but I've added > >> > Florian Weimer to CC who is part of Red Hat's product security group] > >> >=20 > >> > > So I think the following would make sense to allow TLS in NBD. > >> > >=20 > >> > > This would extend the newstyle negotiation by adding two options (= i.e., > >> > > client requests), one server reply, and one server error as well as > >> > > extend one existing reply, in the following manner: > >> > >=20 > >> > > - The two new commands are NBD_OPT_PEEK_EXPORT and NBD_OPT_STARTTL= S. The > >> > > former would be used to verify if the server will do TLS for a g= iven > >> > > export: > >> > >=20 > >> > > C: NBD_OPT_PEEK_EXPORT > >> > > S: NBD_REP_SERVER, with an extra field after the export name > >> > > containing flags that describe the export (R/O vs R/W state, > >> > > whether TLS is allowed and/or required). > >>=20 > >> IMHO the server should never provide *any* information about the expor= ted > >> volume(s) until the TLS layer has been fully setup. ie we shouldn't on= ly > >> think about the actual block data transfers, we should protect the ent= ire > >> NBD protocol even metadata related operations. > > > > This makes sense. >=20 > Seconded. Mmm. I suppose the NBD_OPT_PEEK_EXPORT message could be defined so that it is fine for an export which has the "TLS required" bit set to provide differing information after TLS has been negotiated. > > TLS is about the transport, not about a particular NBD export. The only > > thing that should be communicated is STARTTLS. >=20 > 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? As I've said before in this discussion, encryption downgrade attacks are not specific to STARTTLS; as soon as you have have an "encrypted" and an "unencrypted" variant of a protocol, that becomes a problem. After all, if an attacker can modify the communication so that STARTTLS is filtered out of the communication, they can most likely also redirect all traffic to a decrypting/encrypting proxy. The only way to fix that is through userspace; make "opportunistic" TLS (i.e., use it if available, but move on if not) difficult to achieve. > See also https://www.agwa.name/blog/post/starttls_considered_harmful A random blog post by an author who is speaking about STARTTLS in general terms is not a good technical argument for why STARTTLS is a bad idea in *this* specific case. If I was defining a new protocol from scratch, I might dump the whole thing in TLS to begin with. But that's just not the case, so I have to deal with what exists already. In addition, with the current state of affairs, it is *not possible* to swap to an NBD device if you need to pipe its data through a separate socket than the one you're handing to the kernel. The result of that is that you can't do TLS on a device you want to swap to. This means we need to continue to support a protocol that can do TLS for some exports, and plain (unencrypted) traffic for other exports, *in the same running nbd-server instance*. I did add the NBD_REP_ERR_TLS_REQD message for a server which does not export anything unencrypted, so that it can (after the initial few exchanges) reply to anything except for STARTTLS with "lalala, I'm not listening until you encrypt things". However, unless it's fine to ditch support for swapping to an NBD device (not an option from where I'm standing), dropping support for unencrypted communication is not an option. --=20 It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJURYRTAAoJEMKUD5Ub3wqdEGMQALJa3KXPVkOz5uBt6o7b/4K0 86bFqMUz8Ah6YGBkfQi1rjPAQMpkmiDzJpi0jNlcHSKIlVVgHuOfrZOqnHk5Hh4n dyNMfxwYtkvGgch/0jhGpIPij40ba1Q8SpojTPpjbjv7cFqi0hUn9hRcx9tzfgLD GDX76tQZmEUgF4kbWUoUCGmCfrtmnIMYAx7LsRQjfe6IagcB5eAIl9C0sr3XDlrN I7lH1odTcJYr1vtRiEXIlkVu7miVWXwOrkbmfdJ/VVPuELM34wJI0HRpGtKadx6z SvA0lMoLu3zRBoytYGngk75DttTsCg3Ef8+pPQ0gFwwBm+/8x+LbA2yT0CFEIzsb l7kX/mvH0OpA4yHf6LgjKzVhGctxB0SELvnTdrt2Z//DOHAbuuL7a0U+pD6iiWrF N2NCWbSnv3bIrHPSpr4O6RSsCsCvI4j18E30IUH+aG9w/BLq6a+jlIVQ5GbuFHug TJ/vt8Qne3GhZ5dscdL2+CmB/Ze724aiFTB0V8ITJ3OVcrTYsqDjG8DL0C3uLcLf eBtMqgKWiqXeyYXZaAZvKHoo3puod23UeEKZe/gSQsR7gMMlG8QvF0o5tlu5cBey k1rZbA/fyS0A+bxYxxEkUTjQ1XuJ6cW2I5W5RPekAVnWJyvPuyQLIQi7EQ24IcQU TtsDTMCKWPthMQVJ0L5f =hoLZ -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/--