Re: [libvirt] NBD TLS support in QEMU
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.
- 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.
IMO, it is more fool proof add some --use-tls flag to the client and server
implementations to wrap the data in TLS, just like HTTPS does for instance.
Also, so mean of verification is required (otherwise, back to point 0 being
vulnerable to sslstrip style attacks) either that the server's cert is signed
with a certain (self-generated) CA certificate or that it matches a certain
fingerprint. Doing it similarly on the server-side would allow hitting a 2nd
bird (authentication.)
The NBD protocol starts with a negotiation phase. This would be the
appropriate place to indicate that TLS will be used. After client and
server complete TLS setup the connection can continue as normal.
Besides QEMU, the userspace NBD tools (http://nbd.sf.net/) can also be
extended to support TLS. In this case the kernel needs a localhost
socket and userspace handles TLS.
Thoughts?
Stefan