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 ? Yes. > > > 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 ? Yes. > > > 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. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
