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

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

Well, that's true, in a way, but sample.com isn't a unified entity.
The idea of hacks like this is that if sample.com is a large company
with a lousy IT department and example.com is, say, a financial web
site where people enter their social security and pin number to log
in, you can, by hijacking the traffic intended for example.com, and
collect personal information.

I'm not quite sure how germane this is under SSL because there may be
tight enough restrictions on the way that host names are interepreted
that it isn't an issue - but things like this were major sources of
security holes back in the early nineties when I was last dealing with
these sorts of issues.

In any case it seems you've chosen to keep this simple for now, which
means that it isn't necessary for either of us to understand where the
pitfalls might be in some more complex approach.

...Robert