On 12/31/2015 01:16 PM, George Woodring wrote:
I went and look and we have the ssl_renegotiation_limit set to the
default, which the documentation says is 0.
Well that was the low hanging fruit:)
Given that you see this:
Dec 31 14:04:03 iprobe002 kernel: iPoller2.pl[16044] general protection
ip:7f677fde112c sp:7fff5db9e328 error:0 in SSLeay.so[7f677fd6a000+94000]
I would suggest asking Net::SSLeay folks if they have any idea. A look here:
https://metacpan.org/pod/Net::SSLeay#KNOWN-BUGS-AND-CAVEATS
might also help.
Thanks,
George
iGLASS Networks
www.iglass.net <http://www.iglass.net>
On Thu, Dec 31, 2015 at 3:16 PM, Adrian Klaver
<adrian.kla...@aklaver.com <mailto: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> <http://www.iglass.net>
--
Adrian Klaver
adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com>
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
