Re: SSL connection issue via perl

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: George Woodring <george(dot)woodring(at)iglass(dot)net>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: SSL connection issue via perl
Date: 2015-12-31 21:23:47
Message-ID: 56859CE3.3040507@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)com>
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message gkhan 2015-12-31 21:34:17 Re: to_timestamp alternatives
Previous Message George Woodring 2015-12-31 21:16:42 Re: SSL connection issue via perl