From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: should libpq also require TLSv1.2 by default? |
Date: | 2020-06-26 21:27:44 |
Message-ID: | 31488.1593206864@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> SSL_R_UNKNOWN_PROTOCOL seem to covers cases when someone manages to perform
> something which OpenSSL believes is a broken SSLv2 connection, but their own
> client-level code use it to refer to SSL as well as TLS. Maybe it's worth
> adding as a belts and suspenders type thing?
No objection on my part.
> Is this targeting v13 or v14? In case of the former, the release notes entry
> for raising the default minimum version should perhaps be tweaked as it now
> just refers to the GUC which is a tad misleading.
I think Peter is proposing that we change this in v13. I didn't look
at the release notes; usually we cover this sort of thing in-bulk
when we update the release notes later in beta.
> If anything it might useful to document in the comment that we're only
> concerned with TLS versions, SSL2/3 are disabled in the library initialization.
Good point.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2020-06-26 21:48:23 | Re: pg_dump bug for extension owned tables |
Previous Message | Tom Lane | 2020-06-26 21:24:27 | Re: Possible NULL dereferencing (src/backend/tcop/pquery.c) |