From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "'John R Pierce *EXTERN*'" <pierce(at)hogranch(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PosgreSQL Security Architecture |
Date: | 2016-02-15 10:48:25 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B537F9766@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | FarjadFarid(ChkNet) | 2016-02-15 13:55:41 | Re: PosgreSQL Security Architecture |
Previous Message | Johann Kerdal | 2016-02-15 09:54:16 | Manage SCD 2 table using the INSERT --- ON CONFLICT |