Re: OpenSSL key renegotiation with patched openssl

Recently openssl has been patched to not renegotiate keys.

http://www.links.org/?p=780

After a certain amount of data has gone through a postgresql connection
the server will attempt to switch session keys.

What is the workaround (if any ) to avoid this in postgresql ?

Dave

Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> Recently openssl has been patched to not renegotiate keys.
> http://www.links.org/?p=780
> After a certain amount of data has gone through a postgresql connection
> the server will attempt to switch session keys.
> What is the workaround (if any ) to avoid this in postgresql ?

Install the updated openssl library. Why are you bugging us about
an openssl patch?

regards, tom lane

Tom Lane wrote:
> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>
>> Recently openssl has been patched to not renegotiate keys.
>> http://www.links.org/?p=780
>> After a certain amount of data has gone through a postgresql connection
>> the server will attempt to switch session keys.
>> What is the workaround (if any ) to avoid this in postgresql ?
>>
>
> Install the updated openssl library. Why are you bugging us about
> an openssl patch?
>
> regards, tom lane
>
After applying the updated openssl library slony dies, presumably
because the server requests a new session key

Dave

Tom Lane wrote:
> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>
>> Recently openssl has been patched to not renegotiate keys.
>> http://www.links.org/?p=780
>> After a certain amount of data has gone through a postgresql connection
>> the server will attempt to switch session keys.
>> What is the workaround (if any ) to avoid this in postgresql ?
>>
>
> Install the updated openssl library. Why are you bugging us about
> an openssl patch?
>
> regards, tom lane
>

After applying the updated openssl library slony dies, presumably
because the server requests a new session key

Dave

Dave Cramer <davecramer(at)gmail(dot)com> writes:
> Tom Lane wrote:
>> Install the updated openssl library. Why are you bugging us about
>> an openssl patch?

> After applying the updated openssl library slony dies, presumably
> because the server requests a new session key

The discussion I saw suggested that you need such a patch at both ends.

regards, tom lane

Tom Lane wrote:
> Dave Cramer <davecramer(at)gmail(dot)com> writes:
>> Tom Lane wrote:
>>> Install the updated openssl library. Why are you bugging us about
>>> an openssl patch?
>
>> After applying the updated openssl library slony dies, presumably
>> because the server requests a new session key
>
> The discussion I saw suggested that you need such a patch at both ends.

and likely requires a restart of both postgresql and slony afterwards...

Stefan

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> Tom Lane wrote:
>> The discussion I saw suggested that you need such a patch at both ends.

> and likely requires a restart of both postgresql and slony afterwards...

Actually, after looking through the available info about this:
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
I think my comment above is wrong. It is useful to patch the
*server*-side library to reject a renegotiation request. Applying that
patch on the client side, however, is useless and simply breaks things.

regards, tom lane

On Fri, Nov 27, 2009 at 4:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>> Tom Lane wrote:
>>> The discussion I saw suggested that you need such a patch at both ends.
>
>> and likely requires a restart of both postgresql and slony afterwards...
>
> Actually, after looking through the available info about this:
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> I think my comment above is wrong.  It is useful to patch the
> *server*-side library to reject a renegotiation request.  Applying that
> patch on the client side, however, is useless and simply breaks things.
>
>                        regards, tom lane

I've looked at the available patches for openssl, and so far can only
see that ssl3_renegotiate returns 0 if a renegotiation is requested,
which would cause pg to throw an error. Is there another patch that
fixes this ? I would have expected openssl to simply ignore this
request if renegotiation is removed from the library ?

Dave
>

2009/11/27 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>> Tom Lane wrote:
>>> The discussion I saw suggested that you need such a patch at both ends.
>
>> and likely requires a restart of both postgresql and slony afterwards...
>
> Actually, after looking through the available info about this:
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
> I think my comment above is wrong.  It is useful to patch the
> *server*-side library to reject a renegotiation request.  Applying that
> patch on the client side, however, is useless and simply breaks things.

I haven't looked into the details but - is there a point for us to
remove the requests for renegotiation completely? Will this help those
that *haven't* upgraded their openssl library? I realize it's not
necessarily our bug to fix, but if we can help.. :) If a patched
version of openssl ignores the renegotiation anyway, there's nothing
lost if we turn it off in postgresql, is there?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> I haven't looked into the details but - is there a point for us to
> remove the requests for renegotiation completely?

The periodic renegotiations are a recommended security measure.
Fixing one hole by introducing a different attack vector doesn't
seem to me to be an improvement. Also, when would we undo it?
At least with the current situation, there is an incentive for
people to get a corrected version of openssl as soon as possible
(not "patched", since what this patch does is break essential
functionality; but actually fixed).

regards, tom lane