Re: [libvirt] NBD TLS support in QEMU
On Fri, Sep 05, 2014 at 09:46:18AM +0100, Hani Benhabiles wrote:
On Wed, Sep 03, 2014 at 05:44:17PM +0100, Stefan Hajnoczi wrote:
> Hi,
> QEMU offers both NBD client and server functionality. The NBD protocol
> runs unencrypted, which is a problem when the client and server
> communicate over an untrusted network.
>
> The particular use case that prompted this mail is storage migration in
> OpenStack. The goal is to encrypt the NBD connection between source and
> destination hosts during storage migration.
>
> I think we can integrate TLS into the NBD protocol as an optional flag.
> A quick web search does not reveal existing open source SSL/TLS NBD
> implementations. I do see a VMware NBDSSL protocol but there is no
> specification so I guess it is proprietary.
Not sold on this because:
- It requires (unnecessary) changes to the NBD specification.
They may not be necessary from a libvirt/qemu point of view, but I've
had requests to implement encryption from other people, too. So while
they're not very high on my priority list, I do think the changes are
necessary.
- It would still be vulnerable to a protocol downgrade attack: ie. An
attacker
could strip the TLS flag from the server's response resulting in either:
* Connection fallback to cleartext, if both ends don't force TLS.
* Loss of backward compatibility, if one of the ends forces TLS, making the
reason for which such a flag is added moot IIUC.
Tunneling the entire protocol inside an SSL connection doesn't fix that;
if an attacker is able to hijack your TCP connections and change flags,
then this attacker is also able to hijack your TCP connection and
redirect it to a decrypting/encrypting proxy.
I agree that preventing a possible SSL downgrade attack (and other forms
of MITM) should be high on the priority list, but "tunnel the whole
thing in SSL" doesn't do that.
[...]
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22