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/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
