[Csync2] csync2 and recent gnutls

Lars Ellenberg lars.ellenberg at linbit.com
Mon Sep 21 23:28:29 CEST 2009


On Mon, Sep 21, 2009 at 08:51:56PM +0200, Giampaolo Tomassoni wrote:
> Recent gnutls packages use pkg-config instead of the gnutls-config one.
> Also, I even experienced some troubles with gnutls-2.8.3 due to the fact
> some entries in the libgnutls-openssl.so library are GNUTLS_PRIVATE there,
> instead of being public the way they used to be.
> 
> Due to this, the csync2 package fails to configure and build against these
> gnutls versions.
> 
> In order to overcame these troubles, of course we need to fix the automake
> and autoconfig files (aclocal.m4). But the real problem to me is that we
> can't rely on libgnutls-openssl.so anymore.
> 
> Since the libgnutls-openssl.so is only a compatibility library mapping the
> openssl API into the gnutls one, I think the best way to go is to modify the
> csync2 ssl code to directly use the gnutls API.
> 
> I'm developing a patch fixing configure and switching to the native gnutls
> API, but I'm experiencing some problems with the client certificate
> authentication and I need some help from people already using csync2 with
> certs.
> 
> How did you do these certs? I mean, I read paper.pdf so I know how they are
> created. But you have a single cert_key and cert pair copied to all the
> nodes of the group, or instead each node of the group has its own cert_key
> and cert pair?
>
> This is because I discovered that a gnutls client sends its authenticating
> certificate to the server iff the client certificate is signed by one of the
> CAs the server announces to known to the client. Since I believe most csync2
> certs are self-signed, it may be that two different cert_key and cert pair
> wouldn't work with csync2.
> 
> Can someone check this with some old csync2 ? I can't...

Have a look at conn.c, conn_check_peer_cert().

As long as the peer presents _any_ certificate,
and there happens to be a match with what is returned by "SELECT
certdata FROM x509_cert WHERE peername = '%s'", that is accepted.

If there is no cert registered yet for that peername
in the x509_cert table, the presented cert will be accepted and
inserted.

If there is already a cert registered for that peername,
and the presented cert differs from the stored cert,
the connection will be rejected with "wrong SSL cert".

There is not even a call to SSL_get_verify_result()!

So if you want to be sure that the peer connecting is in fact the
one he pretends to be, you'd need to place the certificate into that
database before hand...



While at it...

Rather than implementing yet again some web of trust between your
servers, I think it would be more useful to get rid of ssl in csync2,
replacing it with a "pipe mode" via some "tunnel" keyword in the config
file.  The $tunnel command would then be invoked with the peer name to
connect to, and "--" "/usr/sbin/csync2" (the second one possibly being a
(per-peer?) config parameter as well).

For starters, I would be fine without the generic "tunnel" method, and
hardcode the only likely candidate, namely ssh, for some special command
line option.  For example tunnel="ssh -l root -o BatchMode=yes".  

We can then reuse all the power of the ssh infrastructure,
forced commands, strong authentications and all the rest you
are familiar with already.

The client side would need to be changed in conn.c, conn_open().

The server side could trigger that mode on stdin being a pipe,
and the presence of the SSH_CLIENT environment variable.

For that, the first part of csync_daemon_session() in daemon.c
would need to be changed so it would not do the getpeername() on its
stdin, but maybe trust the SSH_CLIENT environment variable.

Later, the case A_HELLO: needs to be reworked, to catch accidental
misconnections (example: resolved SSH_CLIENT not matching HELLO string.)


Does that make sense?


-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.


More information about the Csync2 mailing list