Re: PosgreSQL Security Architecture - Mailing list pgsql-general

From Albe Laurenz
Subject Re: PosgreSQL Security Architecture
Date
Msg-id A737B7A37273E048B164557ADEF4A58B537F9766@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to Re: PosgreSQL Security Architecture  (John R Pierce <pierce@hogranch.com>)
Responses Re: PosgreSQL Security Architecture
List pgsql-general
John R Pierce wrote:
> On 2/12/2016 5:20 AM, Lesley Kimmel wrote:
>> Thanks for the reply Laurenz. Of course the first thing that I thought
>> of to prevent man-in-the-middle was SSL. However, I also like to try
>> to address the issue in a way that seems to get at what they are
>> intending. It seemed to me that they wanted to do some configuration
>> within the database related to session IDs.
> 
> when the connection is broken, the process exits and the session ceases
> to exist.     there are no 'session IDs' to speak of (they are process
> IDs instead, but a new process mandates new authentication, there's no
> residual authorizations associated with a PID).

I might be misunderstanding, but is there any connection to a
man-in-the-middle attack?

Without SSL, anybody who can tap into the TCP communication can inject
SQL statements.  No session ID is required.

Yours,
Laurenz Albe

pgsql-general by date:

Previous
From: Johann Kerdal
Date:
Subject: Manage SCD 2 table using the INSERT --- ON CONFLICT
Next
From: "FarjadFarid\(ChkNet\)"
Date:
Subject: Re: PosgreSQL Security Architecture