Re: PosgreSQL Security Architecture

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

In response to

Responses

Browse pgsql-general by date

  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