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 ? > > 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 ... Another advantage of SASL is that you can switch to use symmetric crypto from publickey crypto should public key encryption receive another setback (ie switch form TLS to GSSAPI). Shared secrets are much harder to "break" than public key crypto in some conditions, or simply require different types of attacks, but with HTTP/TLS you have no option but to use public key crypto. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
