[syslog-ng] SSL certificate verification

Balazs Scheidler bazsi at balabit.hu
Wed Mar 9 18:52:37 CET 2011


On Wed, 2011-03-09 at 00:35 +0100, Peter Eckel wrote:
> Hi Baszi, 
> 
> > I'm not sure I followed you correctly, but the syslog-ng server has no
> > information about the client name, only its IP address, which usually
> > doesn't match anything in the X.509 certificate. (although I know that a
> > subjectAltName can be specified with type iPADDr),
> 
> that would be one option I had in mind. The other one would be to reverse-lookup the host name and try to match the result against the CN. 

Well, yes, even though that'd be reliance on DNS, which may (in most
cases) may not be trusted.

> 
> > but that's usually missing.
> 
> Since I create the certificates myself and control all the hosts logging to the central server, I could easily include the IP as well as some alternative form of host name (FQDN vs. simple).
> 
> > You could use the trusted_dn() option to specify which client DNs a given server accepts, but that could mean that you need separate ports for each client.

maybe supporting some kind of templating within trusted_dn()? Like
SSLRequire in Apache, as described here:

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html

The trouble is that syslog-ng already has a templating system, but that
only works in message context, whereas we need to evaluate this _before_
accepting a message.

> 
> You're right, that's not an option. 
> 
> > What do you expect syslog-ng to behave in this case?
> 
> As you already suggested: 
> 
> - try to lookup the host name and match the result against the CN or some subjectAltName
> - try to match the IP against some subjectAltName 
> - fail if the client cannot provide any certificate proving his identity.
> 
> I just did some tests aiming to prove that stunnel does it exactly like that ... unfortunately this wasn't possible, as stunnel obviously follows the same logic Syslog NG does, and so I didn't prove anything except that my own assumption was wrong. But I still think it would be feasible and a very useful functionality, too. 

Generally all SSL enabled servers do it like syslog-ng, at least in my
experience.

> 
> Thank you very much and best regards, 

Since there's a subject validation code in syslog-ng, one would only
need to call it in the client case too. See the destination side in
modules/afsocket/afsocket.c, function afsocket_dd_tls_verify_callback()

That could certainly be applied to the source side too.

As I see if that happens some form of refactoring could be applied,
since this could become part of the TLSContext proper, rather than
having to call it explicitly from each source/destination driver that
may make use of SSL.

for example a:

tls(validate-subject(yes/no))

using defaults as it is now (as a client "yes", as a server "no") would
probably work.

That would expect the client IP address in the CN or in subjectAltName.

Care to give it a spin?

-- 
Bazsi



More information about the syslog-ng mailing list