[Csync2] csync2 and recent gnutls

['Lars Ellenberg']

On Tue, Sep 22, 2009 at 09:11:43AM +0200, Giampaolo Tomassoni wrote:
> > 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?

Probably ;)

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

Well, no.
Did you try that?
It won't work.

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

Right.

> Cheers,
> 
> Giampaolo
> 
> PS: The attached patch IS UNFINISHED!

Thanks, will have a look.


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