Just to continue the above, I can confirm that adding a simple call
to SSL_CTX_set_session_id_context() to be_tls_init() with some arbitrary
const value fixes the error for me. Attached is a patch (ideally a test
should be done for this, but that's beyond what I can invest at the moment,
let me know if it's absolutely necessary).

On Mon, Jul 31, 2017 at 1:15 AM, Shay Rojansky <r...@roji.org> wrote:

> Hi Tom.
> Again, I know little about this, but from what I understand PostgreSQL
> wouldn't actually need to do/implement anything here - the session ticket
> might be used only to abbreviate the SSL handshake (this would explain why
> it's on by default without any application support). In other words, simply
> setting the session context id may make the problem go away and at the same
> time unlock the abbreviated SSL handshake optimization. I could be wrong
> about this though.
> Whether the above is correct or not, SSL resumption - which removes a
> network roundtrip from the connection process - may be a worthy
> optimization even for long-lived connections such as PostgreSQL, although
> obviously much less valuable than, say, short-lived HTTP connections.
> But regardless, it seems that as you say: if you *don't* want to support
> resumption, you're required to explicitly disable it with
> Just to give some context, Npgsql has its own, internal TLS implementation
> which does not implement session tickets at the client side - this is the
> workaround currently used. However, it would be much better if the standard
> .NET SSL implementation could be used instead (i.e. I'm hoping a backport
> would be possible here).
> On Sun, Jul 30, 2017 at 10:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I wrote:
>> > I think what you need to do is tell SslStream not to expect that PG
>> > servers will do session resumption.  (I'm a bit astonished that that
>> > would be its default assumption in the first place, but whatever.)
>> Actually, after a bit of further googling, it seems that the brain
>> damage here may be on the server side.  It seems that OpenSSL will
>> send a session ticket if requested, even though the surrounding
>> application has given it no means to identify the session (!?).
>> Apparently we need to pass SSL_OP_NO_TICKET to SSL_CTX_set_options
>> to prevent that from happening.
>>                         regards, tom lane

Attachment: openssl-set-session-id-context.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to