Re: Allow ssl_renegotiation_limit in PG 9.5

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "'Shay Rojansky *EXTERN*'" <roji(at)roji(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "Pgsql-hackers(at)postgresql(dot)org" <Pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow ssl_renegotiation_limit in PG 9.5
Date: 2015-10-16 09:33:51
Message-ID: A737B7A37273E048B164557ADEF4A58B50FB9A51@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Shay Rojansky wrote:
> Just to give some added reasoning...
>
> As Andres suggested, Npgsql sends ssl_renegotiation_limit=0 because we've seen renegotiation bugs with
> the standard .NET SSL implementation (which Npgsql uses). Seems like everyone has a difficult time
> with renegotiation.

As far as I remember, that was introduced because of renegotiation bugs with Mono:
http://lists.pgfoundry.org/pipermail/npgsql-devel/2010-February/001074.html
http://fxjr.blogspot.co.at/2010/03/ssl-renegotiation-patch.html

Of course, with renegotiation disabled, nobody knows whether there would also have been renegotiation
problems since Npgsql switched from Mono SSL to .NET SSL ...

> As Tom suggested, it gets sent in the startup packet so that DISCARD/RESET ALL resets back to 0 and
> not to the default 512MB (in older versions). Npgsql itself issues DISCARD ALL in its connection pool
> implementation to reset the connection to its original opened state, and of course users may want to
> do it themselves. Having SSL renegotiation accidentally turned on because a user sent RESET ALL, when
> the SSL implementation is known to have issues, is something to be avoided...

Maybe Npgsql could switch to sending the statement after the connection has been
established and resending it after each RESET ALL?
You could add documentation that people should not use RESET ALL with Npgsql unless they
are ready to disable renegotiation afterwards.

If not, the only solution I can see is for PostgreSQL to not protest if it sees the
parameter in the startup packet.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeevan Chalke 2015-10-16 09:40:13 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Dmitry Vasilyev 2015-10-16 09:23:13 Re: Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”