On Wednesday 01 April 2009 20:37:56 Martijn van Oosterhout wrote:
> On Tue, Mar 31, 2009 at 11:33:26PM +0300, Peter Eisentraut wrote:
> > On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote:
> > > I assume directory permissions controlling access to the socket file
> > > would be enough. You ar
On Tue, Mar 31, 2009 at 11:33:26PM +0300, Peter Eisentraut wrote:
> On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote:
> > I assume directory permissions controlling access to the socket file
> > would be enough. You are going to have to set up SSL certificates
> > anyway for this so isn't th
On Saturday 28 March 2009 00:42:28 Bruce Momjian wrote:
> I assume directory permissions controlling access to the socket file
> would be enough. You are going to have to set up SSL certificates
> anyway for this so isn't that just as hard as telling the client where
> the socket file is located?
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> Bruce Momjian wrote:
> >>> I thought the logical solution to this was to place the socket in a
> >>> secure directory and not bother with SSL at all.
> >> How would a client algorithmically determine whether the server
Robert Haas writes:
> On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut wrote:
>> But there is `hostname` and `hostname --fqdn`, both of which are well-defined
>> independent of a connection.
> But they aren't guaranteed to return anything useful, and IME often don't.
I think "well defined" is
On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut wrote:
> On Friday 27 March 2009 14:46:32 Greg Stark wrote:
>> Regarding using the hostname of the system... There's no such thing.
>> Interfaces have names, hosts can have multiple interfaces so the can
>> have multiple names...
>
> But there is `
On Friday 27 March 2009 14:46:32 Greg Stark wrote:
> Regarding using the hostname of the system... There's no such thing.
> Interfaces have names, hosts can have multiple interfaces so the can
> have multiple names...
But there is `hostname` and `hostname --fqdn`, both of which are well-defined
i
Regarding using the hostname of the system... There's no such thing.
Interfaces have names, hosts can have multiple interfaces so the can
have multiple names...
I haven't follwes the discussion so I'm not sure if you have an
existing connection. If so you can get the local interface address
Peter Eisentraut wrote:
> Magnus Hagander wrote:
Perhaps it's enough to add a "localssl" row to pg_hba.conf?
>>> That defeats the point, I think. You don't want the server to determine
>>> whether the client should verify the server.
>>
>> Good point. OTOH, client behavior can be controlled n
Magnus Hagander wrote:
Perhaps it's enough to add a "localssl" row to pg_hba.conf?
That defeats the point, I think. You don't want the server to determine
whether the client should verify the server.
Good point. OTOH, client behavior can be controlled now fine by setting
it to "require" or "p
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
I thought the logical solution to this was to place the socket in a
secure directory and not bother with SSL at all.
How would a client algorithmically determine whether the server socket
was in a "secure" directory?
You have
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I thought the logical solution to this was to place the socket in a
> > secure directory and not bother with SSL at all.
>
> How would a client algorithmically determine whether the server socket
> was in a "secure" directory?
You have to config
Bruce Momjian wrote:
I thought the logical solution to this was to place the socket in a
secure directory and not bother with SSL at all.
How would a client algorithmically determine whether the server socket
was in a "secure" directory?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
Peter Eisentraut wrote:
> I found an old patch on my disk to enable SSL over Unix-domain sockets.
>
> Remember, about a year ago it was discussed that there might also be
> man-in-the-middle or fake-server attacks using Unix-domain sockets,
> because usually anyone can start a server in /tmp. A
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>>> I imagine for example, we could invent an additional sslmode of the sort
>>> prefer-but-not-if-local-socket, which could be the default.
>>
>> That parameter is already pretty complex, not sure it's a great idea to
>> make it even more so :(
>
>
Magnus Hagander wrote:
I imagine for example, we could invent an additional sslmode of the sort
prefer-but-not-if-local-socket, which could be the default.
That parameter is already pretty complex, not sure it's a great idea to
make it even more so :(
I think there is a firm difference betwee
Peter Eisentraut wrote:
> I found an old patch on my disk to enable SSL over Unix-domain sockets.
>
> Remember, about a year ago it was discussed that there might also be
> man-in-the-middle or fake-server attacks using Unix-domain sockets,
> because usually anyone can start a server in /tmp. Aft
I found an old patch on my disk to enable SSL over Unix-domain sockets.
Remember, about a year ago it was discussed that there might also be
man-in-the-middle or fake-server attacks using Unix-domain sockets,
because usually anyone can start a server in /tmp. After an extensive
discussion (ma
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Perhaps the easiest thing to do is to create a (possibly dangling)
> > symlink in /tmp to the real socket in a protected dir.
>
> Cute idea ...
>
> > One thing to be aware of is /tmp cleaners ...
>
> ... but that would definitely b
On Tue, 15 Jan 2008, Tom Lane wrote:
I think on most systems you'd have to explicitly tweak the /tmp-cleaning
script to know not to zap such a link. Given that such a local
customization would probably disappear in your next system update, the
security gain might be fleeting.
Right, on the
>>> On Mon, Jan 14, 2008 at 9:33 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah, all of this is about confusion and error-proneness. I still think
> that the real problem is that we don't have full control over
> client-side code, and therefore can't just write
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> One thing to be aware of is /tmp cleaners ...
>>
>> ... but that would definitely be a problem. I think on most systems
>> you'd have to explicitly tweak the /tmp-cleaning script to know not to
>> zap such a link. Given that such a
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Just for reference: who is it we're worried will check the old
> location? Any client using libpq will use the protected directory
> built into that.
Only if it's using the same copy of libpq that was built with the
server. Also, there are non-
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > One thing to be aware of is /tmp cleaners ...
>
> ... but that would definitely be a problem. I think on most systems
> you'd have to explicitly tweak the /tmp-cleaning script to know not to
> zap such a link. Given that such a lo
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Perhaps the easiest thing to do is to create a (possibly dangling)
> symlink in /tmp to the real socket in a protected dir.
Cute idea ...
> One thing to be aware of is /tmp cleaners ...
... but that would definitely be a problem. I think on most syst
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Yeah, all of this is about confusion and error-proneness. I still think
> >> that the real problem is that we don't have full control over
> >> client-side code, and therefore can't just write off the problem of a
On Mon, Jan 14, 2008 at 10:24:06PM -0500, Bruce Momjian wrote:
> Yea, I figured using protected directories for the socket was the
> zero-cost solution, and if you have to do SSL, might as well just use
> TCP too. (If you moved the socket file to a protected directory I think
> you could use exter
* Alvaro Herrera <[EMAIL PROTECTED]> [080115 07:24]:
> Tom Lane wrote:
>
> > It strikes me that given the postmaster's infrastructure for listening
> > on multiple sockets, it would be a pretty small matter of programming
> > to teach it to listen on socket files in multiple directories not only
>
Tom Lane wrote:
> It strikes me that given the postmaster's infrastructure for listening
> on multiple sockets, it would be a pretty small matter of programming
> to teach it to listen on socket files in multiple directories not only
> one.
The problem with this idea is that if the postmaster goe
Bruce Momjian wrote:
> My feeling on the moving of sockets risk is that you are probably going
> to have all your clients using the new socket directory before anyone
> tries to put something in /tmp, especially if you have the lock file in
> /tmp as outlined above. To spoof in such a situation y
On Tue, Jan 15, 2008 at 10:10:37AM +0100, Peter Eisentraut wrote:
> Am Montag, 14. Januar 2008 schrieb Tom Lane:
> > If we do want to apply Peter's patch, I think it needs to be extended so
> > that the default behavior on sockets is the same as before, ie, no SSL.
> > This could be done by giving
Am Montag, 14. Januar 2008 schrieb Tom Lane:
> If we do want to apply Peter's patch, I think it needs to be extended so
> that the default behavior on sockets is the same as before, ie, no SSL.
> This could be done by giving libpq an additional connection parameter,
> say "socketsslmode", having th
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, all of this is about confusion and error-proneness. I still think
>> that the real problem is that we don't have full control over
>> client-side code, and therefore can't just write off the problem of a
>> client deciding to con
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yea, I figured using protected directories for the socket was the
> > zero-cost solution, and if you have to do SSL, might as well just use
> > TCP too. (If you moved the socket file to a protected directory I think
> > you could use
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yea, I figured using protected directories for the socket was the
> zero-cost solution, and if you have to do SSL, might as well just use
> TCP too. (If you moved the socket file to a protected directory I think
> you could use external_pid_file='/tmp/.s
Tom Lane wrote:
> Conclusions:
>
> * SSL, even without real authentication, is *way* too expensive to
> enable by default.
>
> * The extra cost of going across a local TCP connection is measurable,
> but it's insignificant compared to the cost of turning on SSL. (This
> is on a Fedora 8 kernel B
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It has been reported that the data transmission overhead is much less
> than the connection establishing overhead, which is measured here.
> But this is certainly not an encouraging measurement, if we want to
> put this close to the default path of use
Mark Mielke wrote:
> Does the patch handle patched clients connecting to unpatched servers
> and vice versa?
Yes, it is all compatible.
> Cryptographic
> authentication and encrypted data stream cost is high compared to no
> cryptographic authentication or encrypted data streams. I don't know if
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Here is a patch that implements "localssl" as well. It is quite simple.
The other area that would need some thought before we could consider
this "done" is the behavior of libpq's sslmode parameter. With the
patch as given,
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Here is a patch that implements "localssl" as well. It is quite simple.
The other area that would need some thought before we could consider
this "done" is the behavior of libpq's sslmode parameter. With the
patch as given, an SSL-capable libpq wi
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> > this just works. I didn't find a way to sniff a Unix-domain socket,
> > however.
> >
> > How should we proceed with this?
>
> I am confused by the shortness of this patc
On Fri, Jan 04, 2008 at 02:37:03PM -0500, Bruce Momjian wrote:
> The problem with adding SSL to local sockets is this slippery slope
> where we only do part of the job, but it isn't clear where to draw the
> line.
I don't think "part of the job" for a patch is a slippery slope. It's what
you do w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, it would plug the hole without fully implementing SSL control on
> > local sockets. However, the hole is already plugged by using directory
> > permissions so I question the need for a partial solution at this point
> > in 8.3.
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, it would plug the hole without fully implementing SSL control on
> local sockets. However, the hole is already plugged by using directory
> permissions so I question the need for a partial solution at this point
> in 8.3.
As already noted, "fix /tm
* Bruce Momjian <[EMAIL PROTECTED]> [080104 13:00]:
> > Actually, if you just commit that patch *without* pg_hba modifications,
> > it still solves the problem stated, no? Because the client can be
> > configured to require ssl and to require server certificate validation,
> > and that's the hole
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
> >>> Peter Eisentraut wrote:
> Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> this just works. I didn't find a way to sniff a Uni
Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
>>> Peter Eisentraut wrote:
Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
this just works. I didn't find a way to sniff a Unix-domain socket,
however.
Peter Eisentraut wrote:
> Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
> > Peter Eisentraut wrote:
> > > Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> > > this just works. I didn't find a way to sniff a Unix-domain socket,
> > > however.
> > >
> > > How should we
Am Freitag, 4. Januar 2008 schrieb Bruce Momjian:
> Peter Eisentraut wrote:
> > Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> > this just works. I didn't find a way to sniff a Unix-domain socket,
> > however.
> >
> > How should we proceed with this?
>
> I am confused
Peter Eisentraut wrote:
> Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> this
> just works. I didn't find a way to sniff a Unix-domain socket, however.
>
> How should we proceed with this?
I am confused by the shortness of this patch. Right now pg_hba.conf
has:
On Fri, Jan 04, 2008 at 05:13:21PM +0100, Peter Eisentraut wrote:
> Using the attached patch, SSL will act over Unix-domain sockets. AFAICT,
> this
> just works. I didn't find a way to sniff a Unix-domain socket, however.
Looks clear enough. You should be able to test if it works by using
stra
Using the attached patch, SSL will act over Unix-domain sockets. AFAICT, this
just works. I didn't find a way to sniff a Unix-domain socket, however.
How should we proceed with this?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../cvs-pgsql/src/backend/postmaster/post
52 matches
Mail list logo
