Re: Successor of MD5 authentication, let's use SCRAM

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Will Crawford <billcrawford1970(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Successor of MD5 authentication, let's use SCRAM
Date: 2012-10-23 06:49:52
Message-ID: CAAZKuFbqQPs0jv9gPYZgrXbxoP-gG+Rd2jOh6F3UkuArduMcQQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 22, 2012 at 3:54 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> We could go even further:
> INFO: Server identity "ACME Debian Machine" certified by "Snakeoil CA"
> WARNING: Server identity signed by unknown and untrusted authority "Snakeoil CA"
> HINT: Add either the server certificate or the CA certificate to
> "/usr/lib/ssl/certs" after verifying the identity and certificate hash
>
> SSL is notoriously hard to set up, it would go a long way to give the
> sysadmin an immediate pointer to what certificates are being used and
> where to find or install the CA certs. It might be worth mentioning
> the GUC parameter names to control these things too.

Are the possible locations of certs that libpq reads in always so
short and definitive? Is it clear that the user would always want to
fix the cert situation in that way? What if they don't have file
system access to the remote database and would like to learn its
public key anyway (ala SSH trust on first use).

Overall, I do very much like the sentiment: less guesswork around
where the heck to put things or what to search for in documentation.

--
fdr

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lars Kanis 2012-10-23 08:09:40 Failing SSL connection due to weird interaction with openssl
Previous Message Tom Lane 2012-10-23 02:07:04 Re: [Bug] SELECT INSTEAD with sub-query