[syslog-ng] SSL certificate verification

[Matthew Hall]

On Wed, Mar 09, 2011 at 11:57:10PM +0100, Peter Eckel wrote:
> 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.

If DNS may not be trusted, then why do web browsers compare the DNS name 
with the name in the server certificate, and complain or block the 
connection if there is a mismatch? This argument here is not right.

Sure It's less trusted without DNSSEC but certainly more trusted than 
just accepting any client certificate your CA issued even if it's for a 
totally different system (because, for example, it was stolen by an 
attacker and not yet added to a CRL, etc.)

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

I think it makes more sense to check the DNS because all the machine's 
IP can reverse-resolve to the machine's primary DNS name, and it avoids 
hard-coding IPs into client certificates which is presumably undesirable 
in a large environment of the sort where client certificates would add 
much value.

Regards,
Matthew.