On Thu, Feb 02, 2017 at 10:07:28AM +0000, Stefan Hajnoczi wrote: > On Wed, Feb 01, 2017 at 11:59:53PM +0000, Ketan Nilangekar wrote: > > Patch for secure implementation in libqnio is available for review here: > > > > https://github.com/VeritasHyperScale/libqnio/pull/12 > > > > libqnio client initialization now has an option to use X.509 certificates > > to authenticate itself to the vxhs server. > > Also each client IO request now includes an instance id that is used by the > > vxhs server to authorize the request. > > A test client has also been added. > > Libqnio.so so is renamed to libvxhs.so. We will rename the repository once > > the latest patches are merged. > > QEMU patch to use the new secure interface will follow shortly. > > I have left comments on specific lines of code on GitHub. > > The server should do something based on the client X.509 certificate. > Is the code actually verifying certificates on the client side? > > Right now the code is just going through the motions of SSL but not > protecting against man-in-the-middle attacks. > > I noticed that the code uses OpenSSL. QEMU uses GnuTLS instead of > OpenSSL. In practice it's hard to avoid duplication of SSL libraries: > GlusterFS and Ceph use OpenSSL and NSS. That means QEMU KVM may drag in > GnuTLS, OpenSSL, and NSS! But from a QEMU point of view it would be > nicest to use GnuTLS to keep extra library dependencies minimal.
These points are all reasons why libqnio should not do anything TLS related at all. It should delegate all actual I/O to QEMU, so that we can use our existing QIO logic for TLS that is tried & tested, as well as integrating with existing QEMU infrastructure. ie, ability to use object_add QMP command to register TLS certificates with QEMU, instead of hardcoding their location on disk in libqnio Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
