Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

On 08/04/2017 08:48 PM, Shay Rojansky wrote: On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote: > I'm still not convinced of the risk/problem of simply setting the session > id context as I explained above (rather than disabling the optimization), > but of course either solution

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Awesome, thanks!! On Fri, Aug 4, 2017 at 11:54 PM, Tom Lane wrote: > Shay Rojansky writes: > > 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? > > Already done,

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Shay Rojansky writes: > 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? Already done, will be in next week's minor releases. (You timed this bug report well.)

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

> > > 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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

> > On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote: > > I'm still not convinced of the risk/problem of simply setting the session > > id context as I explained above (rather than disabling the optimization), > > but of course either solution resolves my problem. > > How would that do anything?

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Shay Rojansky writes: > I tested the patch. Thanks! > 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 >

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote: > I'm still not convinced of the risk/problem of simply setting the session > id context as I explained above (rather than disabling the optimization), > but of course either solution resolves my problem. How would that do anything? Each backend

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

I tested the patch. 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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

One more note: https://github.com/netty/netty/pull/5321/files is an equivalent PR setting the session ID context to a constant value in netty (which is also a server using OpenSSL). This is in line with the documentation on SSL_CTX_set_session_id_context (

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

> > Shay Rojansky writes: > > Once again, I manged to make the error go away simply by setting the > > session id context, which seems to be a mandatory server-side step for > > properly support session tickets. > > The fact that you made the error go away doesn't make this a good

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Shay Rojansky writes: > Once again, I manged to make the error go away simply by setting the > session id context, which seems to be a mandatory server-side step for > properly support session tickets. The fact that you made the error go away doesn't make this a good solution. In

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Hi Tom and Heikki. As Tom says, session caching and session tickets seem to be two separate things. However, I think you may be reading more into the session ticket feature than there is - AFAICT there is no expectation or mechanism for restoring *application* state of any kind - the mechanism is

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Heikki Linnakangas writes: > I agree with Tom that we don't really want abbreviated SSL handshakes, > or other similar optimizations, to take place. PostgreSQL connections > are quite long-lived, so we have little to gain. But it makes the attack > surface larger. There have

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

On 07/31/2017 02:24 AM, Shay Rojansky wrote: 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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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,

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

Shay Rojansky writes: > When trying to connect with Npgsql to PostgreSQL with client authentication > (PG has ssl_ca_file set), the first connection works just fine. The second > connection, however, fails and the PostgreSQL logs contain the message > session id context

[HACKERS] PostgreSQL not setting OpenSSL session id context?

Dear hackers, a long-standing issue reported by users of the Npgsql .NET driver for PostgreSQL may have its roots on the PostgreSQL side. I'm far from being an SSL/OpenSSL expert so please be patient if the terms/analysis are incorrect. When trying to connect with Npgsql to PostgreSQL with client