[syslog-ng] SSL certificate verification

[Balazs Scheidler]

On Wed, 2011-03-09 at 18:52 +0100, Balazs Scheidler wrote:
> 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.

well, this is easy to misunderstand what I wrote. I wanted to write, it
may not be trusted in most cases.

> 
> > 
> > > 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