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:02:39
Message-ID: 603c8f070812010702k7c3d57ean92408e7f4fad30d7@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.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: David E. WheelerDate: 2008-12-01 15:02:59
Subject: Re: New to_timestamp implementation is pretty strict
Previous:From: David E. WheelerDate: 2008-12-01 14:56:52
Subject: Re: New to_timestamp implementation is pretty strict

pgsql-committers by date

Next:From: Magnus HaganderDate: 2008-12-01 15:05:50
Subject: Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Previous:From: Magnus HaganderDate: 2008-12-01 14:49:38
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