PostgreSQL - SSL error: sslv3 alert handshake failure

Databases
1
  • If you use a secure connection to PostgreSQL
  • After some time there has to be a renegotiation between client and server
  • Standard this is after each 512 MB of SQL (postgresql.conf: search for “ssl_renegotiation_limit”)

When this happens on an SQL-instruction, you get an error: “SSL error: sslv3 alert handshake failure”
The instruction seems to be successfully executed when I look into the database. But connection is broken after this instruction.

My question about this:
Is the instruction ALWAYS successfully executed when you get this “error”?

2

I never ran into this myself. Is setting ssl_renegotiation_limit to 0 an option for you?

3

SSL libraries from before November 2009 are insecure when using SSL renegotiation due to a vulnerability in the SSL protocol. As a workaround fix for this vulnerability, some vendors shipped SSL libraries incapable of doing the renegotiation. If any of these libraries are in use on the client or server, SSL renegotiation should be disabled. Set to zero.

4

http://www.postgresql.org/docs/9.3/static/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SECURITY

5

Also, there is the need to update SSL libs on Xojo and your PostgreSQL server to avoid possible old security threats, and after, you could probably re-enable the option and see if it’s ok. http://heartbleed.com/

6

The current fixed OpenSSL version is 1.0.1g, to see if your server is vulnerable, check the libs release date.

If your server is a Linux based one, do the following:

sudo openssl version -a

Then check the “built on:” line. It must show a date AFTER April 6 of 2014.

If you use Ubuntu 12.04 or newer, to fix your server side, do the following:

sudo apt-get dist-upgrade.

This will bring your Ubuntu up to date with the latest security patches, including this fix.

7

Thanks for the answers.
After excessive tests I came to the following conclusions:

  • If you get this error, the last instruction is always successfully executed if the instruction was correct.
  • A close and reopen will let you continue working on this connection
  • Recordsets keep working (movenext/moveprevious/eof/…) after reopening the connection
  • All instructions in a transaction until this point aren’t committed because of the reopening (not acceptable)

So since transactions fail this way, I will disable the renegotiation for now.