Обсуждение: postgres-8.4SS, pg_dump from macosx-10.6 has "ssl handshake error" 26% in

hi,

i'm having a little openssl problem with pg_dump over a wireless
lan with postgres-8.4SS (on linux) from enterprisedb and
a macosx-10.6 client.

when i run pg_dump from a wired linux client it's always fine
but since i switched from a macosx-10.4 laptop to a
macosx-10.6 laptop, every time i run pg_dump from the laptop
over the wireless lan, it's fine for a few minutes and then,
26% of the way in, it stalls and never completes.

the postgres logs show many repeated instances of the following
messages:

  payrollLOG:  SSL renegotiation failure
  payrollSTATEMENT:  COPY public.table_name (id, ...
  payrollLOG:  SSL error: ssl handshake failure

there's no special openssl configuration on the laptop
that i'm aware of.

all connections to postgres use ssl.
there are no client certificates.

both psql and pg_dump on the laptop link to the same
libssl (/usr/lib/libssl.0.9.7.dylib) and i never have
trouble with pgsql.

it's odd that the postgres installation on the server
contains its own libssl.so.4 but the installation on the
client (same version) doesn't have its own and uses one
of the system supplied ones. no doubt there's some good
reason for that.

so it probably has something to do with openssl on the mac.
any ideas?

cheers,
raf

raf <raf@raf.org> writes:
> i'm having a little openssl problem with pg_dump over a wireless
> lan with postgres-8.4SS (on linux) from enterprisedb and
> a macosx-10.6 client.

> when i run pg_dump from a wired linux client it's always fine
> but since i switched from a macosx-10.4 laptop to a
> macosx-10.6 laptop, every time i run pg_dump from the laptop
> over the wireless lan, it's fine for a few minutes and then,
> 26% of the way in, it stalls and never completes.

What this sounds like is you've got an openssl library with deliberately
broken renegotiate behavior.  Google for CVE-2009-3555 to learn
something about why that might be.

Assuming that "8.4SS" actually means 8.4.3 or later, you can work around
this by setting ssl_renegotiation_limit to zero in the server.  But it'd
be better to get a copy of libssl with an actual fix, rather than a
braindead kluge, for the CVE problem.

I'm not real sure which of the two ssl libraries you've got is at fault
(they might both be :-()

            regards, tom lane

Tom Lane wrote:

> raf <raf@raf.org> writes:
> > i'm having a little openssl problem with pg_dump over a wireless
> > lan with postgres-8.4SS (on linux) from enterprisedb and
> > a macosx-10.6 client.
>
> > when i run pg_dump from a wired linux client it's always fine
> > but since i switched from a macosx-10.4 laptop to a
> > macosx-10.6 laptop, every time i run pg_dump from the laptop
> > over the wireless lan, it's fine for a few minutes and then,
> > 26% of the way in, it stalls and never completes.
>
> What this sounds like is you've got an openssl library with deliberately
> broken renegotiate behavior.  Google for CVE-2009-3555 to learn
> something about why that might be.
>
> Assuming that "8.4SS" actually means 8.4.3 or later, you can work around
> this by setting ssl_renegotiation_limit to zero in the server.  But it'd
> be better to get a copy of libssl with an actual fix, rather than a
> braindead kluge, for the CVE problem.

the latest enterprisedb standard server is only 8.4.1 (New! 13-Oct-09) :-)

> I'm not real sure which of the two ssl libraries you've got is at fault
> (they might both be :-()

both sides are using 0.9.7 so they're both vulnerable.

i can probably replace the server's copy of libssl with a more
recent version. the client end is a bit trickier. it's using
a system libssl but both 0.9.7 and 0.9.8 are present in the
same directory and it's using 0.9.7. no, removing 0.9.7 or
overwriting it with 0.9.8 doesn't work. i didn't think it
would. :)

i think i'll have to switch from enterprisedb's standard
server to the core distribution to get the latest version
which hopefully uses the more recent libssl.

many thanks.

>             regards, tom lane

cheers,
raf

the latest enterprisedb standard server is only 8.4.1 (New! 13-Oct-09) :-) 

Sachin Srivastava wrote:

> >the latest enterprisedb standard server is only 8.4.1 (New! 13-Oct-09) :-)
>
> By using the StackBuilder Plus application, you can upgrade your server
> to 8.4.4.
>
> --
> Regards,
> Sachin Srivastava
> EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
> <http://www.enterprisedb.com> company.

thanks but it didn't work for me (on debian 5 stable). it
comes with most but not all of the x11-related libraries it
needs. i installed the missing libraries and got errors
about one of its libraries not having version information
that was needed by libcairo. i then disabled its version of
that library in favour of the system's one and stopped
getting library-related error messages but it then just
announced that it couldn't initialise gtk.

the good news is that the one-click installer for the core
distribution detected and happily upgraded the existing
standard server installation. yay enterprisedb!

cheers,
raf

raf wrote:

> Sachin Srivastava wrote:
>
> > >the latest enterprisedb standard server is only 8.4.1 (New! 13-Oct-09) :-)
> >
> > By using the StackBuilder Plus application, you can upgrade your server
> > to 8.4.4.
> >
> > --
> > Regards,
> > Sachin Srivastava
> > EnterpriseDB <http://www.enterprisedb.com>, the Enterprise Postgres
> > <http://www.enterprisedb.com> company.
>
> thanks but it didn't work for me (on debian 5 stable). it
> comes with most but not all of the x11-related libraries it
> needs. i installed the missing libraries and got errors
> about one of its libraries not having version information
> that was needed by libcairo. i then disabled its version of
> that library in favour of the system's one and stopped
> getting library-related error messages but it then just
> announced that it couldn't initialise gtk.
>
> the good news is that the one-click installer for the core
> distribution detected and happily upgraded the existing
> standard server installation. yay enterprisedb!

but it still has the same old libssl which was my main
reason for wanting to upgrade. oh well, it's good to
upgrade the database at least.

cheers,
raf