Обсуждение: 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@fastcrypt.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@fastcrypt.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@gmail.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@gmail.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@kaltenbrunner.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
Tom Lane wrote: > Dave Cramer <pg@fastcrypt.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
On Fri, Nov 27, 2009 at 4:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Stefan Kaltenbrunner <stefan@kaltenbrunner.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@sss.pgh.pa.us>: > Stefan Kaltenbrunner <stefan@kaltenbrunner.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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.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