Thread: How to ensure that SSL is enabled?
I've appended ?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory to the connection URL, but (looking at the network traffic) no encryption appears to be done. Shouldn't the connection fail if no SSL connection can be established? It's possible that the server isn't set up properly; is there a simple way to test that (e.g. verify that the server was compiled with SSL support etc)?
On Mon, 2009-10-19 at 17:31 -0700, Eric Jain wrote:
It looks like on the JDBC side is mostly handled via custom SSLFactory classes. There's been discussion of making the "ssl" param take a string value, allowing more control over behaviour:
http://archives.free.net.ph/message/20070706.205109.cdd3ca05.en.html
... but I don't know if much ever came of it.
Personally, I handle this on the server side in pg_hba.conf . For Internet users (0.0.0.0/0 IP/mask), I use "hostssl" entries rather than simple "host" entries, so the pg_hba.conf entry only matches for SSL connections. If they're not using SSL, the server won't let them try password auth because there's no pg_hba.conf entry that'd permit them to do so.
eg:
hostssl somedatabase all 0.0.0.0/0 md5
--
Craig Ringer
I've appended ?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory to the connection URL, but (looking at the network traffic) no encryption appears to be done. Shouldn't the connection fail if no SSL connection can be established? It's possible that the server isn't set up properly; is there a simple way to test that (e.g. verify that the server was compiled with SSL support etc)?
It looks like on the JDBC side is mostly handled via custom SSLFactory classes. There's been discussion of making the "ssl" param take a string value, allowing more control over behaviour:
http://archives.free.net.ph/message/20070706.205109.cdd3ca05.en.html
... but I don't know if much ever came of it.
Personally, I handle this on the server side in pg_hba.conf . For Internet users (0.0.0.0/0 IP/mask), I use "hostssl" entries rather than simple "host" entries, so the pg_hba.conf entry only matches for SSL connections. If they're not using SSL, the server won't let them try password auth because there's no pg_hba.conf entry that'd permit them to do so.
eg:
hostssl somedatabase all 0.0.0.0/0 md5
--
Craig Ringer
On Mon, Oct 19, 2009 at 20:45, Craig Ringer <craig@postnewspapers.com.au> wrote: > hostssl somedatabase all 0.0.0.0/0 md5 Thanks! Looks like what's happening is that PGPoolingDataSource is ignoring ssl=true. When I switch to PGSimpleDataSource, an SSL connection is established. Has anyone else encountered this bug -- or is this intentional behavior?
On Mon, 26 Oct 2009, Eric Jain wrote: > On Mon, Oct 19, 2009 at 20:45, Craig Ringer <craig@postnewspapers.com.au> wrote: >> hostssl somedatabase all 0.0.0.0/0 md5 > > Thanks! > > Looks like what's happening is that PGPoolingDataSource is ignoring > ssl=true. When I switch to PGSimpleDataSource, an SSL connection is > established. Looks like PGPoolingDataSource is busted and not just for SSL, but for a wide variety of connection options. There's some code which copies over most of the options one at a time from the DataSource to a ConnectionPoolDataSource and it hasn't been updated in a long time. It would be easy to add SSL to the list, but that code needs to be rewritten to something that's less fragile. See org.postgresql.ds.jdbc23.AbstractJdbc23PoolingDataSource#initialize Kris Jurka
On Tue, 27 Oct 2009, Kris Jurka wrote: > > > On Mon, 26 Oct 2009, Eric Jain wrote: > >> >> Looks like what's happening is that PGPoolingDataSource is ignoring >> ssl=true. When I switch to PGSimpleDataSource, an SSL connection is >> established. > > Looks like PGPoolingDataSource is busted and not just for SSL, but for a > wide variety of connection options. There's some code which copies over > most of the options one at a time from the DataSource to a > ConnectionPoolDataSource and it hasn't been updated in a long time. It > would be easy to add SSL to the list, but that code needs to be > rewritten to something that's less fragile. > Fixed in CVS. Kris Jurka