[Csync2] csync2 and recent gnutls

[Giampaolo Tomassoni]

> 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...

As often happens to me, I wasn't clear at all in my writings.

The patch is almost done (I'm attaching a copy here), but the fact the
server seems unable to get the client certificate. The problem is that a
gnutls client would sent its authenticating certificate iff the signing CA
of the latter had been previously announced by the server. This should
happen even with csync2 code using the old gnutls-openssl approach.

Since paper.pdf is quite generic about generating nodes certicates and I
don't have handy any SSL-based csync2 setup, I was asking here how people
generated their own certificates. This is because in the "openssl req" phase
of the sequence suggested in paper.pdf, one can specify many fields which
will end to be part of the DN of the certificate. Since it will be a
self-signed certificate, they will happen to be also the ones of the CA.

My idea is that most csync2 ssl users just used the default values in each
node OR used the same certificate in each node. This would allow the server
to announce the DN of its own certificate and then obtain the client one,
since the client certificate would have the same DN.

Am I right?


> 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).

I'm not implementing a web-of-trush at all. I'm just rewriting the csync2
ssl code to use gnutls_* calls instead of SSL_*...

I would like to have the patched csync2 to be compatible with existing
clients.

Infact, once done I would also like to have someone test it against and old
client and an old server. Anybody willing to?


> 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?

Yes and no.

- Yes because I frankly don't see why csync2 adopts ssl this way. As you
pointed out, a csync2 server in ssl mode stores the client certificate in
the db at first connect and compares it at any subsequent connect. But why?
This is quite useless because the server checks that the client is using the
correct shared key anyway, so why store the certificate in the db or even
ask for it? The adoption of ssl by csync2 makes sense mostly to stop
lurkers. Al the client-certificate-store-and-compare stuff is only added
burner and a headache-generator in case you have to reinstall a node.
However, your suggestion would break existing ssl clients.

- It doesn't make sense to me because you may use ssh with csync2 already:
just put a "nossl * *" line in your csync2.cfg and invoke the server with
the -i option.

I personally use an IPSec-protected extranet to connect my nodes, keep
timers in sync, share services hidden to internet, and run csync2 sessions
between them. SSL is for web servers.


Cheers,

Giampaolo

PS: The attached patch MAY BE UNFINISHED WORK!


> 
> 
> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBDR and LINBITR are registered trademarks of LINBIT, Austria.
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csync2-1.34-pure-gnutls.patch.bz2
Type: application/octet-stream
Size: 33128 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/csync2/attachments/20090922/a5055837/attachment-0001.obj>