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

Re: Spoofing as the postmaster

From: "Trevor Talbot" <quension(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Sullivan" <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spoofing as the postmaster
Date: 2007-12-28 19:54:55
Message-ID: 90bce5730712281154k5e69a768m21b9bb1bb53feb1e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 12/28/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Trevor Talbot" <quension(at)gmail(dot)com> writes:

> > There's a fundamental problem that you can't make someone else do
> > authentication if they don't want to, and that's exactly the situation
> > clients are in. I don't see how this can possibly be fixed anywhere
> > other than the client.

> The point of requiring authentication from the server side is that it
> will get people to configure their client code properly.  Then if a MITM
> attack is subsequently attempted, the client code will detect it.

But this is essentially just an education/training issue; the security
model itself is unchanged. Bank web sites are only going to accept
clients via SSL, but if a client does not try to authenticate the
site, whether it connects via SSL or not is rather irrelevant.

I have no problem with the idea of encouraging clients to authenticate
the server, but this configuration doesn't help with defaults. It's
just available as a tool for site administrators to use.

> Also, getting people in the habit of setting up for mutual
> authentication does have value in that scenario too; it makes the new
> user perhaps a bit more likely to distrust a server that isn't
> presenting the right certificate.

I see Naz's argument as addressing this goal. The problem with forcing
authentication is that it's an all-or-nothing proposition: either the
server and all the clients do it, or none of them do. That's fine when
you control all the pieces and are willing to put in the work to
configure them all, but not effective for encouraging default
behavior.

Instead, give the server credentials by default, but let clients
choose whether to request them. That makes deployment easier in that
all you have to do is configure clients as needed to get
authentication of the server. Easier deployment means it's more likely
to be used.

IOW, put up both http and https out of the box. You might even want to
have newer clients default to caching credentials on the first
connect.

That still doesn't change the security model, but should be more
effective at getting clients to do something useful by default.

In response to

pgsql-hackers by date

Next:From: Andrew SullivanDate: 2007-12-28 21:57:34
Subject: Re: Spoofing as the postmaster
Previous:From: Tom LaneDate: 2007-12-28 17:29:26
Subject: Re: Selectivity estimation for equality and range queries

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