Re: [HACKERS] PostgreSQL not setting OpenSSL session id context? - Mailing list pgsql-hackers

From Shay Rojansky
Subject Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?
Date
Msg-id CADT4RqCiyDZVCQGaSKFcgpYsgH4gfcqCeyeDy3MeOJdLebhTqA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Doing SSL_CTX_set_session_cache_mode(context, SSL_SESS_CACHE_OFF) doesn't
> have any effect whatsoever - I still have the same issue (session id
> context uninitialized). I suspect session caching is an entirely different
> feature from session tickets/RFC5077 (although it might still be a good
> idea to disable).

Right, we expected that that would have no visible effect, because there
is no way to cache sessions in Postgres anyway.  The main point, if I
understand Heikki's concern correctly, is that this might save some
amount of low-level overhead from clients trying to cache connections.

OK, sounds right (i.e. this is a defensive measure that isn't directly connected to my problem but makes sense).

> Doing SSL_CTX_set_options(context, SSL_OP_NO_TICKET) indeed resolves the
> issue, as expected.

Excellent.  I'll push this patch tomorrow sometime (too late/tired
right now).

Great. Do you think it's possible to backport to the other maintained branches as well, seeing as how this is quite trivial and low-impact?
 
> As I wrote above, I'd remove the #ifdef and execute it always.

The reason I put the #ifdef in is that according to my research the
SSL_OP_NO_TICKET symbol was introduced in openssl 0.9.8f, while we
claim to support back to 0.9.8.  I'd be the first to say that you're
nuts if you're running openssl versions that old; but this patch is not
something to move the compatibility goalposts for when it only takes
an #ifdef to avoid breaking older versions.

(I need to check how far back SSL_SESS_CACHE_OFF goes ... we might
need an #ifdef for that too.)

Ah OK, thanks for the explanation - makes perfect sense.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] pgsql 10: hash indexes testing
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pgsql 10: hash indexes testing