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 are going
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 that
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?
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
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
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 now fine by
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
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
On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 27, 2009 at 9:47 AM, Peter Eisentraut pete...@gmx.net 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
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 socket
was in
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
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 configure your
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
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. After
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
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 :(
I think there
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. After
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 be a problem.
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 the
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 libpq
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 goes
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 you
* 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
one.
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
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
client
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 systems
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 local
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 local
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
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 off the
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
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.
I
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 BTW ...
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
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:
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 connect to
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 patch. Right
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 will
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, an
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
it
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
strace
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
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:
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.
How should we
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 Unix-domain socket,
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 by the
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 proceed with
* 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 we're
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 /tmp's
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 with
51 matches
Mail list logo
