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