Re: PostgreSQL12 and older versions of OpenSSL - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: PostgreSQL12 and older versions of OpenSSL
Date
Msg-id bdb92317-6138-f40c-070d-a357e475a07f@2ndquadrant.com
Whole thread Raw
In response to PostgreSQL12 and older versions of OpenSSL  (Victor Wagner <vitus@wagner.pp.ru>)
Responses Re: PostgreSQL12 and older versions of OpenSSL
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: allocation limit for encoding conversion
Next
From: Alvaro Herrera
Date:
Subject: Re: Hypothetical indexes using BRIN broken since pg10