diff options
author | Eric Blake <eblake@redhat.com> | 2016-04-14 16:02:23 -0600 |
---|---|---|
committer | Timothy Pearson <tpearson@raptorengineering.com> | 2019-11-29 20:03:49 -0600 |
commit | 582363f81e61f75ccc3cb2ab58c7d610995c0590 (patch) | |
tree | 83c2364c7fb0dd44d458900af582b97fc6dd0825 /slirp/slirp.h | |
parent | a0057ae143a2bd3652efab0e743a14d76f970dbb (diff) | |
download | hqemu-582363f81e61f75ccc3cb2ab58c7d610995c0590.zip hqemu-582363f81e61f75ccc3cb2ab58c7d610995c0590.tar.gz |
nbd: Don't kill server on client that doesn't request TLS
Upstream NBD documents (as of commit 4feebc95) 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 is programmed to talk to
such a server, and does not do NBD_OPT_STARTTLS first, but rather
wants to probe if it can use a non-encrypted export.
The NBD protocol documents that we should let such a client
continue trying, on the grounds that maybe the client will get the
hint to send NBD_OPT_STARTTLS, rather than immediately dropping
the connection.
Note that NBD_OPT_EXPORT_NAME is a special case: since it is the
only option request that can't have an error return, we have to
(continue to) drop the connection on that one; rather, what we are
fixing here is that all other replies prior to TLS initiation tell
the client NBD_REP_ERR_TLS_REQD, but keep the connection alive.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-id: 1460671343-18485-1-git-send-email-eblake@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'slirp/slirp.h')
0 files changed, 0 insertions, 0 deletions