Re: PostgreSQL12 and older versions of OpenSSL

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSQL12 and older versions of OpenSSL
Date: 2019-09-24 21:52:48
Message-ID: bdb92317-6138-f40c-070d-a357e475a07f@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-09-24 09:18, Victor Wagner wrote:
> Problem is that some code in src/backend/libpq/be-secure-openssl.c
> assumes that if preprocessor symbols TLS1_1_VERSION and TLS1_2_VERSION
> are defined in the openssl headers, corresponding versions of TLS are
> supported by the library.
>
> It is not so. Here is exempt from tls1.h header file from the openssl
> 0.9.8j
>
> #define TLS1_VERSION 0x0301
> #define TLS1_1_VERSION 0x0302
> #define TLS1_2_VERSION 0x0303
> /* TLS 1.1 and 1.2 are not supported by this version of OpenSSL, so
> * TLS_MAX_VERSION indicates TLS 1.0 regardless of the above
> * definitions. (s23_clnt.c and s23_srvr.c have an OPENSSL_assert()
> * check that would catch the error if TLS_MAX_VERSION was too low.)
> */
> #define TLS_MAX_VERSION TLS1_VERSION

That's not actually what this file looks like in the upstream release.
It looks like the packagers must have patched in the protocol codes for
TLS 1.1 and 1.2 themselves. Then they should also add the corresponding
SSL_OP_NO_* flags. AFAICT, these pairs of symbols are always added
together in upstream commits.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-09-24 21:53:25 Re: Hypothetical indexes using BRIN broken since pg10
Previous Message Andres Freund 2019-09-24 21:42:04 Re: allocation limit for encoding conversion