Re: SSL connection issue via perl - Mailing list 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.klaver@aklaver.com <mailto:adrian.klaver@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.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com