aboutsummaryrefslogtreecommitdiff
path: root/rules.mak
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2016-04-14 16:02:23 -0600
committerMax Reitz <mreitz@redhat.com>2016-04-15 17:56:56 +0200
commitd1129a8ad96af6bc47404490769a637bcd860493 (patch)
treecb982c9869a1919426e1b74366f5788c744bea31 /rules.mak
parent23994a5f524aa575c7a4b2e5250f17b127d2cf2f (diff)
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 'rules.mak')
0 files changed, 0 insertions, 0 deletions