Re: PATCH: 3/4: Wire encryption with SASL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



With the TLS socket, all data is encrypted on the wire. The TCP socket though
is still clear text.  Fortunately some SASL authentication mechanism can 
also supply encryption capabilities. This is called SSF in SASL terminology.

This patch mandates the use of an SSF capable SASL authentiction mechanism
on the TCP socket. This in effect restricts you to a choise between GSSAPI
and DIGEST-MD5 as your SASL auth methods (the latter is a user/password
based scheme). We also disallow anonymous & plaintext auth methods. If you
really want to run the TCP socket in clear text & with anonymous auth, simply
turn off SASL altogether. Since TLS already provides encryptiuon, if you run
SASL over the TLS socket, we don't place any restrictions on the choice of
SASL auth mechanism.

On the server side I have removed the 'direction' field of the client object.
This was only used on the TLS socket & was intended to track whether the
handshake process was waiting to receive or send. Rather than try to set
this in various places throughout the daemon code, we simply query the
neccessary direction at the one point where we register a FD event handle
with poll(). This makes the code clearer to follow & reduces the chance of
accidentally messing up the state.

The send & receive functions previously would call read vs gnutls_record_recv
and write vs gnutls_record_send depending on the type of socket. If there is
a SASL SSF layer enabled, we have to first pass the outgoing data through
the sasl_encode() API, and pass incoming data through sasl_decode(). So the
send/recive APIs have changed a little, to deal with this codec need and thus
there is also some more state being tracked per connection - we may have to
cache the output for sasl_decode for future calls depending on how much
data we need in short term.


NB, the SSF layer lets you choose a strength factor from 0 -> a large number
and the docs all talk about 

 * 0   = no protection
 * 1   = integrity protection only
 * 40  = 40-bit DES or 40-bit RC2/RC4
 * 56  = DES
 * 112 = triple-DES
 * 128 = 128-bit RC2/RC4/BLOWFISH
 * 256 = baseline AES

This is incredibly misleading. The GSSAPI mechanism in SASL will never report
a strength of anything other than 56. Even if it is using triple-DES. The
true strength of the GSSAPI/Kerberos impl is impossible to figure out from
the SASL apis - you have to trust that the underlying Kerberos impl was 
compiled with suitably strong ciphers - all modern OS use strong ciphers in
Kebreros so I don't think this is a huge issue. If you are truely paranoid
though, you always have the option of using TLS (which gives at least 128
bit ciphers, often 256 bit), and then just using Kerberos for auth and ignore
the SASL SSF layer. This is an site admin config choice.


 qemud/internal.h      |   17 ++-
 qemud/qemud.c         |  207 +++++++++++++++++++++++++++++-------
 qemud/remote.c        |   97 ++++++++++++++++-
 src/remote_internal.c |  283 ++++++++++++++++++++++++++++++++++++++++----------
 4 files changed, 503 insertions(+), 101 deletions(-)


Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]