[syslog-ng] SSL certificate verification

[Peter Eckel]

Hi Baszi, 

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

sure. Although I am currently rolling out DNSSEC step-by-step, which means that there is some progress to expect in the near future. But for most current installation you are of course right, it doesn't make much sense to link a certificate to a name that is not guaranteed to be correct at all. 

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

Seems to be very much effort to me ... one could refer to /etc/hosts based adress resolution (which would work around DNS insecurity), but that's not very scalable as well. 

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

That seems to be the case, yes. Which makes it seem very probable that actually it doesn't make much sense to try to resolve names and match them to the CN/subjectAltName, because if there was a sensible way to do it, someone else would have done it already. 

Last resort would be the IP address, which works fine in subjectAltName for authenticating the server to the client. Can you think of any reason why that could not be feasible as well? 

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

Sure! I am currently including the IP in the subjectAltName for new certificates anyway, so it wouldn't require any change in procedure to test it.

Thanks for your feedback!

Best regards, 

  Peter.