I went and look and we have the ssl_renegotiation_limit set to the default, which the documentation says is 0.
Thanks,
George
iGLASS Networks
www.iglass.net
www.iglass.net
On Thu, Dec 31, 2015 at 3:16 PM, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
On 12/31/2015 11:29 AM, George Woodring wrote:
OS: CentOS 6.6
Postgres Version: 9.3.10
I have a script that is worked for years that does the following
- Connect to postgres and get a list of URLs to poll for status
- close connection
- Start threads to poll the URLs
- cleanup threads and collect the results.
- Connect to postgres and write the url status.
- close connection
We updated perl SSL libraries to the latest version, one of which was
Net::SSLeay 1.35 -> 1.72
Now the script dies without any feedback when attempting the 2nd
connection. The only hint at the problem is
/var/log/messages
Dec 31 14:04:03 iprobe002 kernel: iPoller2.pl[16044] general protection
ip:7f677fde112c sp:7fff5db9e328 error:0 in SSLeay.so[7f677fd6a000+94000]
/var/log/postgresql
Dec 31 14:04:03 iprobe002 postgres[16255]: [4-1] LOG: could not accept
SSL connection: EOF detected
I have worked around the immediate issue by keeping the 1st connection
open for the entire script instead of making 2 connections, but I would
like to try to find out what is going wrong.
Any suggestions would be appreciated.
Might want to take a look at the ssl_renegotiation_limit setting in postgresql.conf and if it is set to > 0, reset to 0 per:
http://www.postgresql.org/docs/9.4/interactive/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SECURITY
"
(integer)
Specifies how much data can flow over an SSL-encrypted connection before renegotiation of the session keys will take place. Renegotiation decreases an attacker's chances of doing cryptanalysis when large amounts of traffic can be examined, but it also carries a large performance penalty. The sum of sent and received traffic is used to check the limit. If this parameter is set to 0, renegotiation is disabled. The default is 0.
Note: SSL libraries from before November 2009 are insecure when using SSL renegotiation, due to a vulnerability in the SSL protocol. As a stop-gap fix for this vulnerability, some vendors shipped SSL libraries incapable of doing renegotiation. If any such libraries are in use on the client or server, SSL renegotiation should be disabled.
Warning
Due to bugs in OpenSSL enabling ssl renegotiation, by configuring a non-zero ssl_renegotiation_limit, is likely to lead to problems like long-lived connections breaking.
"
and this from the 9.5 release notes:
"
Decommission server configuration parameter ssl_renegotiation_limit, which was deprecated in earlier releases (Andres Freund)
While SSL renegotiation is a good idea in theory, it has caused enough bugs to be considered a net negative in practice, and it is due to be removed from future versions of the relevant standards. We have therefore removed support for it from PostgreSQL. The ssl_renegotiation_limit parameter still exists, but cannot be set to anything but zero (disabled). It's not documented anymore, either.
"
Thanks,
George
iGLASS Networks
www.iglass.net <http://www.iglass.net>
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
