[Csync2] Public cluster -- Letting a pre-shared key escape

[Andreas J. Koenig]

>>>>> On Wed, 19 Apr 2006 12:27:18 +0200, Clifford Wolf <clifford at clifford.at> said:

  > unfortunately I have almost no idea about x509 certificates and all that
  > stuff (the best requisites for writing security relevant software for using
  > this techniques ;-) ..

:-O ;)

  > imo it would be great if a admin could create his own CA and then create
  > host keys using this CA, so that csync2 could be configured with the CA
  > public key and would refuse certificates which aren't signed by the
  > configured CA.

Yes, for many setups this would be very helpful. It should be optional
though, because in other setups it might be less convenient than it is
currently.

  > actually it always was my plan to implement ssl in csync2 that way. but my
  > x509 and gnuTLS knowledge isn't sufficient to implement it and I have not
  > time at the moment to learn the missing things..

I completely understand this,,,

  > Andreas, are you interested in and do you know enough about x509 and the
  > gnuTLS api to implement this and send me a patch?

I fear this goes quite beyond my horizon, I do not even speak C.

But I'm very interested in helping to shape the functionality that
needs to be implemented. Maybe if we find the proper words for what we
want, we find somebody to implement it?

I'm really interested in getting the handshake right. I believe there
is much room for improvement. For example I just tested the expiration
day of a certificate. I do not know why openssl insists on an
expiration date. I just wrote this perl program:

====days-until-eot.pl====
#!/usr/bin/perl
print int((2**31-1-time)/86400), "\n";
====eof====

which outputs the number of days until the end of the epoch on 32bit
UNIX system, so that I can set an optimized --days parameter with

   openssl .... -days `days-until-eot.pl` ...

Anyway, I realized that it's a nightmare in a cluster to reach the
expiration date. All partners need to be informed that they have to
remove the record of the expired client from the database. This can
only be done *after* the certificate is updated. Countless hours are
lost on that day for all involved parties. (Or maybe I'm missing
something?)

That's something that needs to be considered also for a setup with a
CA involved.

Then there's the setup I'm trying to implement: one masterserver and a
significant number of anonymous slaves: the slaves are interested in
strong cryptography but the master is not at all: he gives away the
data to anybody like an anonymous ftp server. In this case the demands
on the security are asymmetric.

In gpg it is possible to accumulate certificates somehow: if you
update your certificate with a new expiration date, the old
certificate and the new certificate coexist in one certificate hull.
If we can have this too, we could survive the expiration date without
interruption of services. If we cannot, I know no workaround except
the stupid perl program above:-(

OK, I figure, now it would be nice if a security expert would chime in
and show us the way out:-)

Thanks for 1.31 by the way!
-- 
andreas