F21 Self Contained Change: Remote Journal Logging
zbyszek at in.waw.pl
Wed Apr 16 21:06:21 UTC 2014
On Wed, Apr 16, 2014 at 12:48:21PM -0400, Simo Sorce wrote:
> On Wed, 2014-04-16 at 15:04 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Apr 15, 2014 at 03:30:57PM -0400, Simo Sorce wrote:
> > > > I'd imagine that in a setup with a few servers one would create
> > > > the certificates on the receiver machine, copy&pasting some instructions
> > > > from Fedora docs, and scp them to the other hosts.
> > Hi,
> > in current setup, I require (on both ends) for the certificate on the
> > other to be signed by a specified authority. So some of the questions
> > you ask don't really apply, since the certificates are supposed to be
> > generated specifically for this purpose.
> > > What I am asking is:
> > > How do you validate certificates on the client ?
> > I check if they are signed by a specified authoriy.
> What authority ? Is this a CA ? Or do you allow listing fingerprints of
> self-signed certificates ?
Yes, signed by a specific CA.
> > > Are you going to use white lists ?
> > No.
> So if I have a large domain the only option is to allow all/or nothing,
> or to build many subCAs ?
> > > Are you going to depend on a CA white listed ?
> > Yes.
> > > Are you going to create an extensions to be put in the certificates to
> > > restrict their use to logging ? Or are you going to allow to use any
> > > certificate as long as the CN matches the machine name ?
> > > Are you going to have white lists on the server ?
> > > Are you going to require client certificate authentication, or will you
> > > allow any anonymous client to flood your server with garbage ?
> > The client is authenticated by having a certificate signed by specified
> > authority.
> So you rely on X509 auth, if the client has no cert you refuse the
> connection, correct ?
> > > How do you generate certificates ?
> > > NSS comes with certutil, but it is not very flexible, I am not sure
> > > about wat GnuTLS comes with, but that library is not something I would
> > > like to depend on in the first place.
> > I leave the generation of the certificates to the admin. I personally used
> > openssl so far, but this shouldn't really matter.
> Ok so we are a 3 separate implementations .. wow :)
> > > Also how are you going to harmonize client versus server management, the
> > > 2 stacks (NSS and GnuTLS) are quite different, having to learn not 1 but
> > > 2 stacks seem quite steep.
> > I don't think that's something that the user would care about. On
> > the programming side it's annoying though.
> > > > > Is there any reason why a better custom protocol that can be secured
> > > > > using things like SASL or GSSAPI is not used ?
> > > > It doesn't really fit well with the overall approach of using HTTP. But
> > > > I'm open to suggestions how to do this better. The Change page is so
> > > > obnoxiously detailed so that I can get feedback :)
> > >
> > > If you used something like protobuffers or dbus for the message
> > > formatting and use a socket for the transport where you can choose
> > > whether you want to do TLS vs GSSAPI easily (as you are not tied by the
> > > inability of HTTP to use anything but TLS) then you would have a much
> > > more flexible system. Also you wouldn't be tied to use 2 different
> > > crypto stacks in the same project which is really a shame. You have to
> > > duplicate everything and that will be prone to errors or
> > > incompatibilities and you'll have to use the lower common denominator if
> > > there are feature mismatches.
> > >
> > > You could also eventually tunnel over HTTPS, after it is just buffers
> > > going back and forth, but you wouldn't be tied to it.
> > I'll reconsider using SASL instead. I have the HTTPS-transport version
> > almost ready, so for now I'll go with that, to have a working
> > solution. There's still some other questions, mostly related to how
> > the data should be stored on the receiver, so I want to get it out for
> > people to test. The underlying transport is an implementation detail,
> > mostly visible in the way that authentication is done, so a new
> > transport can be added, and the old one deprecated or even removed.
> > Thank you for those suggestions.
> You are welcome, note that I like the idea of being able to send logs
> remotely, I just want not to be trapped in that horrible thing that is
> HTTPS, it is very bad security wise, we have no choice for the "web" atm
> because browsers are very slow to adopt anything, but we shouldn't tie
> ourselves into this bad world for stuff that is not man to be exposed to
> web browsers.
> Hopefully you'll also make sure the only TLS 1.2 or higher is accepted ?
> I didn't go on a rant on how horrible TLS is in itself, and the amount
> of attacks you can mount to it given it's use of crypto ...
Good point. I haven't modified the defaults, to older versions are
certainly accepted. I'll add it on the list of things to fix.
More information about the devel