> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Gavin McDonald > Sent: Friday, June 11, 2010 10:24 AM > To: [email protected] > Subject: [rsyslog] rsyslog TLS question > > Greetings list, I was hoping you could offer a small piece of advice, > re: > TLS certificates and rsyslog; > > I have a farm of ubuntu instances in the Amazon EC2 cloud, and am > implementing encrypted remote syslogging. In the gssapi documentation, > it > states that it is a bad idea to "use these [host certificates] on more > than > one instance, [because] doing so would prevent [me] from distinguising > between the instances and thus would disable useful authentication." > > This would mean that not only do I have to create over 50 client certs > to > start with, but because of the way in which we currently backup & > provision > EC2 cloud server instances, I would have to generate a new host cert on > every instance reboot. Besides the obvious security concerns, what > effects > would there be from sharing a cert as it is explicitly stated to not > do?
Well, the certificate is the machine's ID. So if you share certificates among different machines, you never know which machine you are talking to. It now depends on your security requirement if that is a problem or not. If it is sufficient to know that the peer you are talking to is one of those that you manage, everything is fine. If you need to set finer-grained permissions, you can probably not take this route. Most often, such finer grained permissions are NOT needed. > How indistinguishable does the log traffic become? Don't remote syslog > messages come with a hostname in plaintext anyway? (Besides, rsyslog > has > templated output too !) The certificat is solely used for access control. It does not affect the hostname as given inside the message. The reason, for example, is relay chains. The RFCs demand mutual authentication, and rsyslog implements it, but there is neither yet a RFC nor a rsyslog implementation that permits only select messages to be received based on certificate permissions. This would be possible, but as noone ever asked for such a feature, I'd suspect that it is not really needed. > Would time-stamp collisions cause logging > failures? > > > If the issues are not unresolvable, my plan is to generate a unique > client > certificate per machine TYPE, (webserver, DB & slaves, load-balancer, > api > proxy, etc.) thus allowing me to continue with our current method of > single-image instance provisioning, while gaining (mostly) secure > centralized logging. I'd appreciate some experienced insight into the > matter, of course, hence this email. I personally find this a very good approach. Note that many real-world applciations use certificates, and certificate chains quite different from the one size fits all approach the the core CAs want to tell us. I know, for example, that folks in healthcare use certificates, but in a similar sense like you suggest BUT they do not use any public CAs and have their own web of trust (as a side-note, this is the reason why rsyslog supports multiple certificates at the same time). Even in healthcare, this is not the only approach. I think it is important to make a good policy decision based on ones own needs. This obviously includes knowing the details of all facts involved and I guess that exactly was the reason for your question ;) And as usual in security: YMMV ;) Rainer > > Regards, > -G > > Gavin McDonald > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
