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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list