Re: BUG #12769: SSL-Renegotiation failures

Retried my test suite after commit

1c2b7c0879d83ff79e4adf2c0a883df92b713da4 Restore the SSL_set_session_id_context() call to OpenSS...

Cloned again from 9.5devel master.
Now the two patches work as expected (Means: errors without patch, no errors
with patch (I can't see, whether the code is really performing renegotiation)).
That seems promising.

As already mentioned:
I would also test the two patches for 9.3
in a production near environment to prove them fixing the reported Bug.
If that isn't desired,
I will clone them from REL9_3_STABLE branch once they are committed.

VlG-Arne

On Sun, 15 Feb 2015, Arne Scheffer wrote:

> On the same machine (CentOS6)
>
> Cloned from 9.5devel,
> ./configure --with-perl --with-openssl --with-python --with-tcl --with-pam
> --with-ldap --enable-thread-safety --enable-debug
> make make install make clean
>
> Repeated the procedure attached in the mail
> Got a different error (also twice at exected renegotiation times):
>
> < 2015-02-15 16:40:45.438 CET >LOG: SSL error: session id context
> uninitialized
> < 2015-02-15 16:40:45.439 CET >LOG: could not receive data from client:
> Connection reset by peer
> < 2015-02-15 16:40:45.439 CET >LOG: unexpected EOF on standby connection
>
> Tried
>
> git checkout -b ssl_patch
> patch -p1 <../0001-Fix-sslv3-alert-unexpected-message-errors-in-SSL-ren.patch
> (got applied on 2 files)
> patch -p1 <../0002-Also-drain-input-buffer-in-non-blocking-mode-if-send.patch
> (got applied on 1 file)
>
> Repeated make make install make clean
>
> Repeated the procedure attached in the mail.
>
> (Both twice.)
>
> Got the same errors.
> Perhaps I did something wrong. Could you add a temporary debug line, so that
> I can
> see, that the patch is really applied in my environment?
>
> Even tried 0003, but no change.
>
> Patch expectedly doesn't apply on 9.3.6:
>
> [root(at)zivwebapp13 postgresql-9.3.6patched]# patch -p1
> <../0001-Fix-sslv3-alert-unexpected-message-errors-in-SSL-ren.patch patching
> file src/interfaces/libpq/fe-misc.c
> Hunk #1 succeeded at 919 (offset -1 lines).
> can't find file to patch at input line 45
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |diff --git a/src/interfaces/libpq/fe-secure-openssl.c
> b/src/interfaces/libpq/fe-secure-openssl.c
> |index a32af34..93b8184 100644
> |--- a/src/interfaces/libpq/fe-secure-openssl.c
> |+++ b/src/interfaces/libpq/fe-secure-openssl.c
> --------------------------
>
> I would also test backpatched patch code once it's made.
>
> VlG
>
> Arne
>
>
> On Sat, 14 Feb 2015, Heikki Linnakangas wrote:
>
>> On 02/13/2015 10:59 PM, Andres Freund wrote:
>>> On 2015-02-13 18:52:02 +0000, pilum(dot)70(at)uni-muenster(dot)de wrote:
>>>> I get ssl renegotiation failures with streaming standbys. Sometimes the
>>>> connection breaks and is reconnected afterwards. However, if I use
>>>> pg_basebackup (same libpq connection string), I don't get any of these
>>>> failures, allthough the transferred data ist far beyond 512 MB
>>>> So I don't think it's the
>>>> ssl renegotiation bug (openssl of a yum update patched centos6)
>>>> If I disable ssl_renegotiation_limit to 0, there are no errors any more,
>>>> but that is only a workaround, no solution.
>>>
>>> Heikki and me have recently investigated problems around SSL
>>> renegotiation. See
>>> http://www.postgresql.org/message-id/20150126101405.GA31719@awork2.anarazel.de
>>> .
>>
>> I wasn't able to reproduce exactly the same error you saw, Arne, so it
>> would be good if you could test the patches I've been developing, to see if
>> they fix your problem too. That is, patches 0001 and 0002 from
>> http://www.postgresql.org/message-id/54DE6FAF.6050005@vmware.com. Could you
>> do that?
>>
>> - Heikki
>>
>