On Mon, Sep 14, 2009 at 09:40:47AM +0200, Saleem Edah-Tally wrote:
> >a separate application server
>
> Well this can be a solution in a trustworthy and friendly environment, on
> which I can't count.
There must be some mis-communication going on; the above is how things
tend to be done on the Internet (e.g. you have code in the web server
that hands off known "good" queries to the database) and the Internet
certainly isn't a "trustworthy and friendly environment".
> I would have been more at ease if libpq could manage a PKCS12 cert. or some
> secure wallet/keystore that contains both the public and private keys for SSL
> traffic. Neither the end user nor any admin would have to provide the password
> to access the keys inside the secured storage as I would have prefered to
> hard-code the password. Hard coding is not an elegant solution I agree, but
> leaving on the table an unencrypted private key is not something to do IMO.
As Tom said; if this is implemented in software on a conventional OS
then this can *never* work. Even if you start using a smart card to do
the crypto things don't get any better, how can you ensure that only the
"right" libpq process is talking to the card.
You need something you trust in the middle, and the conventional answer
to this is another server running code that only you control. The PKI
stuff in libpq is about preventing man-in-the-middle attacks *between*
libpq and the PG server. Your problem is that you don't trust the code
*calling* libpq and I can't think how PKI would help here.
--
Sam http://samason.me.uk/