Re: BUG #5585: SSL problems with long COPYs

Stefan Kaltenbrunner wrote:
> On 08/01/2010 08:33 AM, Karl Denninger wrote:
>> Alex Hunsaker wrote:
>>> On Sun, Aug 1, 2010 at 00:08, Karl Denninger<karl@denninger.net>
>>> wrote:
>>>
>>>> The following bug has been logged online:
>>>>
>>>> Bug reference:      5585
>>>> Logged by:          Karl Denninger
>>>> Email address:karl@denninger.net
>>>> PostgreSQL version: 8.4.4
>>>> Operating system:   FreeBSD 8.0
>>>> Description:        SSL problems with long COPYs
>>>> Details:
>>>>
>>>> This is a copy of a message I posted this evening on the SLONY list.
>>>>
>>>> Synopsis: With SSL ON a large table copy containing a BYTEA field
>>>> fails
>>>> repeatedly a few minutes into the operation.
>>>>
>>>
>>> My guess is its due to the server or client disabling ssl
>>> renegotiation, per the docs:
>>>
>>> ssl_renegotiation_limit (integer)
>>> Specifies how much data can flow over an SSL encrypted connection
>>> before renegotiation of the session will take place. Renegotiation of
>>> the session decreases the chance of doing cryptanalysis when large
>>> amounts of data are sent, but it also carries a large performance
>>> penalty. The sum of sent and received traffic is used to check the
>>> limit. If the parameter is set to 0, renegotiation is disabled. The
>>> default is 512MB.
>>>
>>> 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 also shipped SSL
>>> libraries incapable of doing renegotiation. If any of these libraries
>>> are in use on the client or server, SSL renegotiation should be
>>> disabled.
>>>
>>> Id try setting that to 0 in your postgresql.conf and see if it still
>>> fails.
>>>
>>>
>> I will attempt this but it is at least somewhat unlikely to be the
>> cause, as prior to the failure two tables of over 1GB each did correctly
>> transfer.  They did not, however, have any binary (bytea) fields in
>> them.
>
> how exactly did you measure the 1GB? If that's the on-disk size of the
> table (maybe even including indexes) it is entirely believable that
> the amount of data transfered through COPY on the SSL-session was much
> less than 512MB.
> Given the symthoms reported I would agree with Alex on suspecting a
> broken openssl library.
The reported copy table size in the SLON log.   It exceeded 1GB for two
of the tables the successfully came over before the error.

-- Karl