Re: SSL connection issue via perl - Mailing list pgsql-general

From Adrian Klaver
Subject Re: SSL connection issue via perl
Date
Msg-id 56858D1F.6040708@aklaver.com
Whole thread Raw
In response to SSL connection issue via perl  (George Woodring <george.woodring@iglass.net>)
Responses Re: SSL connection issue via perl  (George Woodring <george.woodring@iglass.net>)
List pgsql-general
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@aklaver.com


pgsql-general by date:

Previous
From: George Woodring
Date:
Subject: SSL connection issue via perl
Next
From: gkhan
Date:
Subject: to_timestamp alternatives