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 On Thu, Dec 31, 2015 at 3:16 PM, Adrian Klaver <adrian.kla...@aklaver.com> 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.kla...@aklaver.com >
