Re: SSL connection issue via perl

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