From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqj9P-0000yC-OQ for qemu-devel@nongnu.org; Thu, 14 Apr 2016 11:25:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqj9L-0001Mo-88 for qemu-devel@nongnu.org; Thu, 14 Apr 2016 11:25:47 -0400 References: <1460060981-5338-1-git-send-email-eblake@redhat.com> From: Eric Blake Message-ID: <570FB66B.3020902@redhat.com> Date: Thu, 14 Apr 2016 09:25:31 -0600 MIME-Version: 1.0 In-Reply-To: <1460060981-5338-1-git-send-email-eblake@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BomrmdJrOG9J3JN7CH0fQfHgKv0e5fl7p" Subject: Re: [Qemu-devel] [PATCH for-2.6] nbd: Don't kill server on client that doesn't request TLS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: pbonzini@redhat.com, alex@alex.org.uk, qemu block This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BomrmdJrOG9J3JN7CH0fQfHgKv0e5fl7p Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [adding qemu-block in cc, since Paolo can't send pull request] On 04/07/2016 02:29 PM, Eric Blake wrote: > Upstream NBD is documenting that servers MAY choose to operate > in a conditional mode, where it is up to the client whether to > use TLS. For qemu's case, we want to always be in FORCEDTLS > mode, because of the risk of man-in-the-middle attacks, and since > we never export more than one device; likewise, the qemu client > will ALWAYS send NBD_OPT_STARTTLS as its first option. But now > that SELECTIVETLS servers exist, it is feasible to encounter a > (non-qemu) client that does not do NBD_OPT_STARTTLS first, but > rather wants to take advantage of the conditional modes it might > find elsewhere. >=20 > Since we require TLS, we are within our rights to drop connections > on any client that doesn't negotiate it right away, or which > attempts to negotiate it incorrectly, without violating the intent > of the NBD Protocol. However, it's better to allow the client to > continue trying, on the grounds that maybe the client will get the > hint to send NBD_OPT_STARTTLS. >=20 > Signed-off-by: Eric Blake > --- >=20 > My earlier patch was arguably incomplete: > https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg01265.html >=20 > But as it is already in a pull request, and as this one is > a bit more controversial, it's best to keep it as a separate patch. >=20 > nbd/server.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) >=20 > diff --git a/nbd/server.c b/nbd/server.c > index 7843584..2b727f0 100644 > --- a/nbd/server.c > +++ b/nbd/server.c > @@ -450,9 +450,12 @@ static int nbd_negotiate_options(NBDClient *client= ) >=20 > default: > TRACE("Option 0x%x not permitted before TLS", clientfl= ags); > + if (nbd_negotiate_drop_sync(client->ioc, length) !=3D = length) { > + return -EIO; > + } > nbd_negotiate_send_rep(client->ioc, NBD_REP_ERR_TLS_RE= QD, > clientflags); > - return -EINVAL; > + break; > } > } else if (fixedNewstyle) { > switch (clientflags) { > @@ -470,6 +473,9 @@ static int nbd_negotiate_options(NBDClient *client)= > return nbd_negotiate_handle_export_name(client, length= ); >=20 > case NBD_OPT_STARTTLS: > + if (nbd_negotiate_drop_sync(client->ioc, length) !=3D = length) { > + return -EIO; > + } > if (client->tlscreds) { > TRACE("TLS already enabled"); > nbd_negotiate_send_rep(client->ioc, NBD_REP_ERR_IN= VALID, > @@ -479,7 +485,7 @@ static int nbd_negotiate_options(NBDClient *client)= > nbd_negotiate_send_rep(client->ioc, NBD_REP_ERR_PO= LICY, > clientflags); > } > - return -EINVAL; > + break; > default: > TRACE("Unsupported option 0x%x", clientflags); > if (nbd_negotiate_drop_sync(client->ioc, length) !=3D = length) { >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --BomrmdJrOG9J3JN7CH0fQfHgKv0e5fl7p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXD7ZrAAoJEKeha0olJ0NqJHAIAJCVr/Wr/s0m0LYs8A4WTmN+ 0JPJNfTO2ImA63bSfimqThBAD1QOMOdO4qZv+0/isjLDIeEOYH5TUgdXB9uLK58z tbvNP8dHNjZlHpvRwYSkPws9uNmPiZypwlxfYM+HqXsGKfI6ZhRt4QHDmxyIHW9H x7XQdNMiLwmZRrtaI6vdhzUE4db1mwKHX/dWhL5utXh/7u/nI6a/9liZoh1wtY/y cdaxk3ogsMXGVQCBHv3CxKpD9uDn17s1RIu4GC2TxqIKZ5nWJl7oM0yRrUHq0fTp 8J5vgMStAIFlj7RCbyhtvQnpYbd0LQ1rHnZc4hrU4Tot1VtONxj4PQ70kVV81sA= =fzFr -----END PGP SIGNATURE----- --BomrmdJrOG9J3JN7CH0fQfHgKv0e5fl7p--