[syslog-ng] SSL certificate verification

[Balazs Scheidler]

Hi,

On Wed, 2011-03-09 at 16:49 -0800, Matthew Hall wrote:
> 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.

Yes, it is. In the 'client' case (e.g. web browser or syslog-ng running
as a client) you know the _name_ of the server since you've entered it
in the URL bar (or the config file), so that's authoritive.

In the server case, all we have is an IP address, reverse-mapping it is
doable, but cannot be trusted.

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

It creates a false sense of security. The way DNS reverse-resolution
works makes it trivial to spoof especially if this is an internet facing
listener.

The way it currently works, is that if you have a key (any key) it'd
work. It doesn't protect against trusted clients exchanging their keys.
But the suggestion in my previous email would solve that too.

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

You have a point here. I guess doing a reverse and then a forward lookup
would not be bad, even though that would mean an extra DNS lookup when
the connection is established. And since this is only an _additional_ 
restriction to having a trusted key, this may be useful.

-- 
Bazsi