Re: [Nbd] [PATCH] Improve documentation for TLS
Daniel,
On 7 Apr 2016, at 12:51, Daniel P. Berrange <berrange@...696...> wrote:
> IMHO, we should not permit what you call OPTIONALTLS or SELECTIVETLS,
> because these open possibilities for a MITM to perform downgrade
> attacks, where the MITM runs TLS to the real server, but runs no-TLS
> to the real client.
Could you describe how a downgrade attack might occur? It's
always open to the client to refuse to access an export (or
the server as a whole) unless TLS is negotiated, as I make
clear here (see last phrase).
> ## Client side requirements
>
> If the client supports TLS at all, it MUST be prepared
> to deal with servers operating in any of the above modes.
> Notwithstanding, a client MAY always disconnect or
> refuse to connect to a particular export if TLS is
> not available and the user requires TLS.
No one should be worried about downgrade attacks on
SELECTIVETLS on the exports that are not TLS only because
clearly that is a risk they have decided to take by making
the exports not TLS only! The only way to avoid a download
attack is to make the export TLS only. SELECTIVETLS
caters for the situation where the server only has some
exports it wishes to secure. I guess it's worth documenting
this, though I thought it was obvious.
OPTIONALTLS copes with the situation where all exports
fall into the above category. Here you are effectively saying
the client and server agree out of band whether TLS
should be compulsory, and the client will reject this if not.
I think you might be making the mistake of coming
at this from the perspective where there is only one export
(possibly because in qemu-nbd as far as I know there is
only ever one export). If you agree there is a use case
for non-tls exports, and a use case for tls exports, it's
difficult to argue there isn't a use case for both.
On 7 Apr 2016, at 12:51, Daniel P. Berrange <berrange@...696...> wrote:
> Both the QEMU NBD server and NBD clients only implement FORCEDTLS.
> ie you tell the client to use TLS and it will refuse to talk to a
> server which doesn't support TLS, and you tell the server to use
> TLS and it will refuse to talk to a client which does not request
> TLS
So using my terminology, FORCEDTLS is something that applies
only to the server, and that's fine if that's how you want
your server to operate (i.e. it is permitted for it to
operate only in FORCEDTLS or NOTLS mode which is what
Qemu does). In qemu-NBD, it uses either FORCEDTLS or
NOTLS depending on the command line - that's just fine
by my proposals.
Re qmeu client, if the (non-qemu) server runs in any of the TLS
modes (apart from 'NOTLS') that will be compatible with the Qemu
server. There will be no downgrade attack possible if the qemu
client errors if it can't negotiate TLS (which it is
intended to do). In qemu, the client's policy toward the
server is determined by the command line as well - if
TLS is specified, it insists the connection be upgraded,
but if it isn't specified, it never tries to upgrade the
connection. That behaviour is just fine by my proposal as
well.
But it doesn't mean the *server* needs to be in FORCEDTLS
mode. Indeed the qemu client operates in exactly this way with
my server, which is SELECTIVETLS - explicitly permitted by the
INFO extension currently, and interoperability is fine. And this
is perfectly compatible behaviour with what I suggest.
Incidentally, the qemu client does not appear to assume the
server is 'FORCEDTLS', and IIRC from time spend staring into
Wireshark yesterday sends its NBD_OPT_LIST prior to the TLS
upgrade. I can check that if you like.
--
Alex Bligh
Reply to: