Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Date
Msg-id 4933FD4E.4040703@hagander.net
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
List pgsql-hackers
Robert Haas wrote:
>>> 2. I can't see any possible way that matching a single component could
>>> create security holes that would be eliminated by matching multiple
>>> components, but I'm more skeptical about the other direction.  What
>>> about the old DNS hack where you create a DNS record for
>>> example.com.sample.com and hijack connections intended for example.com
>>> made by people whose default DNS suffix is sample.com?  There may be
>>> reason to believe this isn't a problem, but matching less seems like
>>> it can't possibly be a bad thing.
>> Right, but that's all about being careful not to give out certs like
>> "*.postgres.*".
> 
> Errrr...no.  The point is that if you've hacked sample.com's DNS
> server, you might have a cert for *.sample.com, but you might NOT have
> a cert for example.com.

Oh, now I see. Yes, it would break on that. But I don't really see the
problem:

* If you have a cert for *.sample.com, you trust sample.com
* All you can do is direct traffic *to* sample.com, which is trusted.

But I guess it could be a potential issue with global CAs, if you just
blindly add them to the trust list.

//Magnus



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: New to_timestamp implementation is pretty strict
Next
From: Alvaro Herrera
Date:
Subject: Re: New to_timestamp implementation is pretty strict