Thread

1. Re: [HACKERS] Query cancel and OOB data

   Tom Lane <tgl@sss.pgh.pa.us> — 1998-05-26T23:28:14Z

   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
   
   

2. Re: [HACKERS] Query cancel and OOB data

   Matthew N. Dodd <winter@jurai.net> — 1998-05-27T01:17:48Z

   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	
   */
   
   
   

3. Re: [HACKERS] Query cancel and OOB data

   ocie@paracel.com — 1998-05-27T02:10:44Z

   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
   
   
   
   

4. Re: [HACKERS] Query cancel and OOB data

   David Gould <dg@illustra.com> — 1998-05-31T08:44:42Z

   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.