| From: | Shay Rojansky <roji(at)roji(dot)org> |
|---|---|
| To: | 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-14 17:52:36 |
| Message-ID: | CADT4RqCkLWhCt5fr1ySmSXYa2LZA8dGGgk5=eKYtxpOtN5-o+g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 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...
Shay
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-10-14 17:56:28 | Re: Can extension build own SGML document? |
| Previous Message | Andres Freund | 2015-10-14 17:50:27 | Re: Proposal: pg_confcheck - syntactic & semantic validation of postgresql configuration files |