On 04/14/2016 03:08 PM, Max Reitz wrote: > On 07.04.2016 22:29, 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. >> >> 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. >> >> Signed-off-by: Eric Blake >> --- >> +++ b/nbd/server.c >> @@ -450,9 +450,12 @@ static int nbd_negotiate_options(NBDClient *client) >> >> default: >> TRACE("Option 0x%x not permitted before TLS", clientflags); >> + if (nbd_negotiate_drop_sync(client->ioc, length) != length) { >> + return -EIO; >> + } >> nbd_negotiate_send_rep(client->ioc, NBD_REP_ERR_TLS_REQD, >> clientflags); >> - return -EINVAL; >> + break; >> } > > What about NBD_OPT_EXPORTNAME? The specification says that this option > does not allow for errors, and so the session must be terminated if this > option is sent in FORCEDTLS mode without TLS having been negotiated. Oh, good catch. v2 coming up. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org