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