Skip site navigation (1) Skip section navigation (2)

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

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Magnus Hagander" <magnus(at)hagander(dot)net>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Date: 2008-12-01 15:34:46
Message-ID: 603c8f070812010734o43913620mfadef73c07b818c7@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
>>>> 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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-12-01 15:35:54
Subject: Re: V2 of PITR performance improvement for 8.4
Previous:From: Greg StarkDate: 2008-12-01 15:33:28
Subject: Re: New to_timestamp implementation is pretty strict

pgsql-committers by date

Next:From: Robert HaasDate: 2008-12-01 15:38:53
Subject: Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Previous:From: Magnus HaganderDate: 2008-12-01 15:31:46
Subject: Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group