Re: [Qemu-devel] [PATCH] Improve documentation for TLS

[Daniel P. Berrange]

On Thu, Apr 07, 2016 at 01:13:10PM +0100, Alex Bligh wrote:
> Daniel,
> 
> On 7 Apr 2016, at 12:51, Daniel P. Berrange <address@hidden> 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).

Right, so that's OK if the client is implementing FORCEDTLS.

If the server policy is OPTIONALTLS, and the client policy
is also OPTIONALTLS, then a MITM can just downgrade to NOTLS
and both client & server will carry on happily in cleartext.

IOW, OPTIONALTLS is offering no meaningful security when
both client & server policy is set that way.  It is only
safe if either the client or server run FORCEDTLS. This
all makes OPTIONALTLS rather pointless, and gives people
a false sense of security when they use it and don't
realize it is trivially downgradable if both sides consider
it as optional.

> > ## 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.

I don't really agree that there's a use case of mixing
tls & non-tls exports in the same server. Sure it is
something you can technically support, but I think it
is really a solution in search of a problem when it comes
to the real world,, and the most likely effect is that
it'll just open the door to accidental security screw
ups by people not understanding its implications.

> On 7 Apr 2016, at 12:51, Daniel P. Berrange <address@hidden> 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.

You say you're only describing these options from the server's POV, but
I think it is clear that they need to be considered from both the client
and server POV in order to evaluate the security characteristics.

> 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.

If the qemu NBD client has TLS credentials set then it will
refuse to connect to a server without TLS. The OPT_TLS is
definitely the first thing it sends, becasue the QEMU NBD
server will reject all options until OPT_TLS has been sent.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|