
-----Original Message-----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Maurice Gittens <mgittens@gits.nl>
Cc: hackers@postgreSQL.org <hackers@postgreSQL.org>
Date: zondag 24 mei 1998 23:52
Subject: Re: [HACKERS] Query cancel and OOB data


>"Maurice Gittens" <mgittens@gits.nl> writes:
>> Assuming that every user has a password which is known by both the client
>> and the server, it seem to me like using a one-way function based on the
>> clientuser password as the secret key (refered to above) is appropiate.
>> This avoids the need for introducing "yet another shared secret into the
>> system".
>
>Well, I think that the cancel security mechanism ought to be per backend
>process, not per user.

I assumed that this was understood.

> That is, simply being the same "Postgres user"
>should not give you the ability to issue a cancel; you ought to be
>required to have some direct association with a particular client/backend
>session.  Access to the client/backend connection channel is one way;
>knowledge of a per-connection secret is another.
>
>Also, isn't it true that not all the supported authentication mechanisms
>use a password?  Taking this approach would mean we have to design a new
>cancel security mechanism for each authentication protocol.
This may be true. The point I'm trying to make is that using one
way-functions
together with a shared secret will make it possible to avoid denial of
service attacks
which rely on replaying the "magic token".

Again I assumed it to be understood that the pid of the particular backend
would exchanged with the client during the initial handshake. It would also
be included (together with the shared secret e.g. the password and
and some form of a sequence id) in the one-way hash.

>
> regards, tom lane

Regards, Maurice.



Sun, 24 May 1998 17:47:04 +0200
"Maurice Gittens" <mgittens@gits.nl>
Re: [HACKERS] Query cancel and OOB data 
"Maurice Gittens" <mgittens@gits.nl> writes:
> This may be true. The point I'm trying to make is that using one
> way-functions together with a shared secret will make it possible to
> avoid denial of service attacks which rely on replaying the "magic
> token".

> Again I assumed it to be understood that the pid of the particular backend
> would exchanged with the client during the initial handshake. It would also
> be included (together with the shared secret e.g. the password and
> and some form of a sequence id) in the one-way hash.

Ah, now I think I see your point: you want to encrypt the cancel request
so that even a packet sniffer could not generate additional cancel
requests after seeing the first one.  That seems like a good idea, but
there is still the problem of what to use for the encryption key (the
"shared secret").  A password would work in those authentication schemes
that have a password, but what about those that don't?

More generally, I think we risk overdesigning the cancel authorization
mechanism while failing to deal with systemic security issues.  Above
we are blithely assuming that a user's Postgres password is secret ...
which it is hardly likely to be against an attacker with packet-sniffing
capability.  I don't think it's worth trying to make the cancel mechanism
(alone) proof against attacks that really need to be dealt with by
using a secure transport method.

			regards, tom lane

Mon, 25 May 1998 12:01:31 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query cancel and OOB data 
Tom Lane wrote:
> 
> "Maurice Gittens" <mgittens@gits.nl> writes:
> > This may be true. The point I'm trying to make is that using one
> > way-functions together with a shared secret will make it possible to
> > avoid denial of service attacks which rely on replaying the "magic
> > token".
> 
> > Again I assumed it to be understood that the pid of the particular backend
> > would exchanged with the client during the initial handshake. It would also
> > be included (together with the shared secret e.g. the password and
> > and some form of a sequence id) in the one-way hash.
> 
> Ah, now I think I see your point: you want to encrypt the cancel request
> so that even a packet sniffer could not generate additional cancel
> requests after seeing the first one.  That seems like a good idea, but
> there is still the problem of what to use for the encryption key (the
> "shared secret").  A password would work in those authentication schemes
> that have a password, but what about those that don't?

Aha!

I'm slowly working through back emails, so I apologize if someone else
already posted this.  If we want to create a shared secret between the
postmaster and the client, we should think about the Diffe-Helman
algorithm.  

For those unfamiliar with this, we start by picking large numbers b
and m.  The client picks a number k and then sends K=b^k%m, while the
server picks a number l and sends L=b^l%m.  The client calculates
L^k%m and the server calculates K^l%m, and these numbers are
identical.  A third party eavesdropping on the conversation would only
get K and L, and would have no idea what the shared number is, unless
they can calculate the computationally infeasible discrete logarithm.

Anyway, something to think about.

Ocie

Tue, 26 May 1998 14:17:16 -0700 (PDT)
ocie@paracel.com
Re: [HACKERS] Query cancel and OOB data
ocie@paracel.com writes:
> If we want to create a shared secret between the
> postmaster and the client, we should think about the Diffe-Helman
> [ discrete logarithm ] algorithm.  

I used Diffie-Hellman for that purpose years ago, and perhaps could
still dig up the code for it.  But I thought discrete logarithm had been
broken since then, or at least shown to be far less intractable than
people thought.  In any case, D-H is pretty slow --- are we prepared to
add seconds to the backend startup time in the name of security?

			regards, tom lane

Tue, 26 May 1998 19:28:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Query cancel and OOB data 
On Tue, 26 May 1998, Tom Lane wrote:
> I used Diffie-Hellman for that purpose years ago, and perhaps could
> still dig up the code for it.  But I thought discrete logarithm had been
> broken since then, or at least shown to be far less intractable than
> people thought.  In any case, D-H is pretty slow --- are we prepared to
> add seconds to the backend startup time in the name of security?

I think everyone is thinking too hard on this issue.

Transport security should be just that.

Use SSL or Kerberos encryption if you wish thoe entire session to be (more
or less) unsnoopable/unspoofable.

Trying to hack things in will only result in an incomplete and/or ugly
solution.

The way I see it people have several choices:

- Run with no network listeners and therefore no network clients to expose
to snooping/spoofing attacks.

- Require SSLed or Kerberized connections, incuring longer startup times
but insuring a secure channel.

- Use SKIP or some other IP level encryption system to provide a secure
'virtual lan' insuring a secure channel.

- Isolate communication across secure, private networks insuring a secure
channel.

So long as we make people aware of the risks they are exposing themselves
to, adding 'security features' in places better left to lower level
protocols is unnecessary.

/* 
   Matthew N. Dodd		| A memory retaining a love you had for life	
   winter@jurai.net		| As cruel as it seems nothing ever seems to
   http://www.jurai.net/~winter | go right - FLA M 3.1:53	
*/


Tue, 26 May 1998 21:17:48 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] Query cancel and OOB data 
Matthew N. Dodd wrote:
> 
> On Tue, 26 May 1998, Tom Lane wrote:
> > I used Diffie-Hellman for that purpose years ago, and perhaps could
> > still dig up the code for it.  But I thought discrete logarithm had been
> > broken since then, or at least shown to be far less intractable than
> > people thought.  In any case, D-H is pretty slow --- are we prepared to
> > add seconds to the backend startup time in the name of security?
> 
> I think everyone is thinking too hard on this issue.
> 
> Transport security should be just that.
> 
> Use SSL or Kerberos encryption if you wish thoe entire session to be (more
> or less) unsnoopable/unspoofable.
> 
> Trying to hack things in will only result in an incomplete and/or ugly
> solution.
> 
> The way I see it people have several choices:
> 
> - Run with no network listeners and therefore no network clients to expose
> to snooping/spoofing attacks.
> 
> - Require SSLed or Kerberized connections, incuring longer startup times
> but insuring a secure channel.
> 
> - Use SKIP or some other IP level encryption system to provide a secure
> 'virtual lan' insuring a secure channel.
> 
> - Isolate communication across secure, private networks insuring a secure
> channel.
> 
> So long as we make people aware of the risks they are exposing themselves
> to, adding 'security features' in places better left to lower level
> protocols is unnecessary.
> 

HMM, you do make a convincing argument.  As one of my H.S. teachers
used to say, we are putting "Descartes before Horace".  Probably
better to just have the postmaster generate and issue a random number
to the client.  

It would be nice if this can be done in a forward/backward-compatible
way.  I.E. old clients that don't know ablout cancelling should be
able to work with servers that can cancel, and newer clients that can
cancel should be able to disable this feature if talking with an older
server.  A rolling database gathers no development community :)

Ocie



Tue, 26 May 1998 19:10:44 -0700 (PDT)
ocie@paracel.com
Re: [HACKERS] Query cancel and OOB data
Matthew N. Dodd writes:
> I think everyone is thinking too hard on this issue.
> 
> Transport security should be just that.
> 
> Use SSL or Kerberos encryption if you wish thoe entire session to be (more
> or less) unsnoopable/unspoofable.
> 
> Trying to hack things in will only result in an incomplete and/or ugly
> solution.
> 
> The way I see it people have several choices:
> 
> - Run with no network listeners and therefore no network clients to expose
> to snooping/spoofing attacks.
> 
> - Require SSLed or Kerberized connections, incuring longer startup times
> but insuring a secure channel.
> 
> - Use SKIP or some other IP level encryption system to provide a secure
> 'virtual lan' insuring a secure channel.
> 
> - Isolate communication across secure, private networks insuring a secure
> channel.
> 
> So long as we make people aware of the risks they are exposing themselves
> to, adding 'security features' in places better left to lower level
> protocols is unnecessary.

Right on. I have been following this discussion about securing the
cancel channel hoping for it to come back to earth and now it has.

All the major systems I am familiar with (Sybase, Informix, Illustra,
MS SQL Server) use TCP as their primary client/server transport and do not
use encryption (most even send cleartext passwords over the wire). Some of
these systems support only TCP.

The assumption is that the dbms and clients are on a private network and not
exposed to the internet at large except through gateways of some kind. 
As I have not heard any horror stories about breakins, denial of service
etc at customer sites in my ten years working with this stuff, I assume
that while it may happen, it does not happen often enough for the customers
to complain to their db vendors about.

The other thing is that security is hard. It is hard to make a system
secure, and it is even harder to make it usable after you make it secure.
And if you don't make it usable, then you find the office and dumpsters filled
with post-its with passwords on them. 

Likewise, most environments are not really secure anyway, it will usually be
easier to hack a root shell and kill the postmaster or copy out the data
base files than to fool around figuring out the postgres on the wire traffic.

-dg

David Gould           dg@illustra.com            510.628.3783 or 510.305.9468
Informix Software                      300 Lakeside Drive   Oakland, CA 94612
 - A child of five could understand this!  Fetch me a child of five.
 

Sun, 31 May 1998 01:44:42 -0700 (PDT)
dg@illustra.com (David Gould)
Re: [HACKERS] Query cancel and OOB data