Horton

Thread

Commits

  1. Fix regression in TLS session ticket disabling

  1. TLS session tickets disabled?

    Cameron Vogt <cvogt@automaticcontrols.net> — 2024-08-12T21:19:22Z

    I recently updated one of my PostgreSQL databases to 16.4. Since updating, I am unable to refresh Power BI reports that rely on the database. The error message in my PostgreSQL server's log file is "could not accept SSL connection: session id context uninitialized". I looked up the error message and found my issue in another mailing list: https://www.postgresql.org/message-id/CADT4RqBU8N-csyZuzaook-c795dt22Zcwg1aHWB6tfVdAkodZA%40mail.gmail.com.

After reading the old thread, it looks like the resolution was to make the PostgreSQL server pass SSL_OP_NO_TICKET to SSL_CTX_set_options. I believe the 16.4 update has resurrected this issue. In the 16.4 release notes, I found a bullet point that says:

"Disable creation of stateful TLS session tickets by OpenSSL.
This avoids possible failures with clients that think receipt of a session ticket means that TLS session resumption is supported."

Would it be possible to get this change reverted in the next update?

Thank you,
Cameron Vogt


Don't forget to RSVP<https://www.punchbowl.com/parties/1042a7af321e873a512c>  for our annual Customer Appreciation Day!

September 20th, 2024, from 11am-3pm


Cameron Vogt | Software Developer
Direct:314-756-2302<tel:314-756-2302> | Cell: 636-388-2050<tel:636-388-2050>
cvogt@automaticcontrols.net

1585 Fencorp Drive<https://www.google.com/maps/dir/38.5384448,-90.43968/Automatic+Controls+Equipment+Systems,+Inc.+Fenton,+MO+63026/@38.5371308,-90.448053,16z/data=!3m1!4b1!4m9!4m8!1m1!4e1!1m5!1m1!1s0x87d8cfa7d0262fa3:0x8de9b691c07a1768!2m2!1d-90.4476712!2d38.5358207>
<https://www.google.com/maps/dir/38.5384448,-90.43968/Automatic+Controls+Equipment+Systems,+Inc.+Fenton,+MO+63026/@38.5371308,-90.448053,16z/data=!3m1!4b1!4m9!4m8!1m1!4e1!1m5!1m1!1s0x87d8cfa7d0262fa3:0x8de9b691c07a1768!2m2!1d-90.4476712!2d38.5358207>Fenton, Missouri 63026<https://www.google.com/maps/dir/38.5384448,-90.43968/Automatic+Controls+Equipment+Systems,+Inc.+Fenton,+MO+63026/@38.5371308,-90.448053,16z/data=!3m1!4b1!4m9!4m8!1m1!4e1!1m5!1m1!1s0x87d8cfa7d0262fa3:0x8de9b691c07a1768!2m2!1d-90.4476712!2d38.5358207>
[cid:aces_66e9dd1e-ddf8-4d47-aa75-b72eea6ea7eb.png]
[cid:supportlink_28817f99-b936-4867-8557-910a1c601d21.png]<https://automaticcontrols.net/request-support/>

  2. Re: TLS session tickets disabled?

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-08-13T18:05:34Z

    Cameron Vogt <cvogt@automaticcontrols.net> writes:
> I recently updated one of my PostgreSQL databases to 16.4. Since updating, I am unable to refresh Power BI reports that rely on the database. The error message in my PostgreSQL server's log file is "could not accept SSL connection: session id context uninitialized". I looked up the error message and found my issue in another mailing list: https://www.postgresql.org/message-id/CADT4RqBU8N-csyZuzaook-c795dt22Zcwg1aHWB6tfVdAkodZA%40mail.gmail.com.
> After reading the old thread, it looks like the resolution was to make the PostgreSQL server pass SSL_OP_NO_TICKET to SSL_CTX_set_options. I believe the 16.4 update has resurrected this issue. In the 16.4 release notes, I found a bullet point that says:

> "Disable creation of stateful TLS session tickets by OpenSSL.
> This avoids possible failures with clients that think receipt of a session ticket means that TLS session resumption is supported."

> Would it be possible to get this change reverted in the next update?

What is your argument that it's not the client that is broken?
AFAIK, it should not be requiring a session ticket to exist.

			regards, tom lane

  3. Re: TLS session tickets disabled?

    Cameron Vogt <cvogt@automaticcontrols.net> — 2024-08-13T20:59:07Z

    I dug into it a little more, and you may be correct that the Power BI client is broken. I was able to retrieve a log file from Power BI, and I've attached the stack trace to this email. The log suggests that NpgSQL may be part of the problem (especially considering that the old 2017 thread was also in reference to NpgSQL). According to https://learn.microsoft.com/en-us/power-query/connectors/postgresql#prerequisites, Power BI relies upon NpgSQL 4.0.10, and it apparently won't work with any later version due to ".NET version incompatibilities".

I ran a few tests to verify if NpgSQL is the problem. Refer to the attached .NET source file: minimal_test.cs. I can successfully create one connection to PostgreSQL 16.4 using NpgSQL 4.0.10, but when I try to create a second connection without closing the first, I get a "could not accept SSL connection: session id context uninitialized" error message. When using the latest version (NpgSQL 8.0.3), I cannot reproduce the error. Thus the ideal solution would be for Microsoft to update Power BI's NpgSQL dependency.

In summary, it seems that NpgSQL 4.0.10 has a bug making it incompatible with PostgreSQL 16.4 in certain cases. I have no control over Power BI and which version of NpgSQL they use, but I can submit a bug report to Microsoft if you think that would be best. I suppose the short-term solution is to downgrade my PostgreSQL server to 16.3 until Microsoft figures out their end.

Thank you,
Cameron Vogt


Cameron Vogt | Software Developer
Direct: 314-756-2302 | Cell: 636-388-2050
1585 Fencorp Drive | Fenton, MO 63026
Automatic Controls Equipment Systems, Inc.

________________________________
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Tuesday, August 13, 2024 1:05 PM
To: Cameron Vogt <cvogt@automaticcontrols.net>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: TLS session tickets disabled?

Cameron Vogt <cvogt@automaticcontrols.net> writes:
> I recently updated one of my PostgreSQL databases to 16.4. Since updating, I am unable to refresh Power BI reports that rely on the database. The error message in my PostgreSQL server's log file is "could not accept SSL connection: session id context uninitialized". I looked up the error message and found my issue in another mailing list: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.postgresql.org_message-2Did_CADT4RqBU8N-2DcsyZuzaook-2Dc795dt22Zcwg1aHWB6tfVdAkodZA-2540mail.gmail.com&d=DwIFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=T46-GxAN5Skc2EVmozD7SN2IexQmZD6kBcLbq8QBSuA&m=Hor0LlyPxpRxGFt45LTAqk9aD5kGH0NB8S-Nuq571G8ApUK0ZbtCwoBi6SRlX7Dk&s=9CDjPoCGGUBc47DX1-Are_QlgJ0vLVZvy9y_4GYROhw&e=.
> After reading the old thread, it looks like the resolution was to make the PostgreSQL server pass SSL_OP_NO_TICKET to SSL_CTX_set_options. I believe the 16.4 update has resurrected this issue. In the 16.4 release notes, I found a bullet point that says:

> "Disable creation of stateful TLS session tickets by OpenSSL.
> This avoids possible failures with clients that think receipt of a session ticket means that TLS session resumption is supported."

> Would it be possible to get this change reverted in the next update?

What is your argument that it's not the client that is broken?
AFAIK, it should not be requiring a session ticket to exist.

                        regards, tom lane

  4. Re: TLS session tickets disabled?

    Cameron Vogt <cvogt@automaticcontrols.net> — 2024-08-14T21:59:53Z

    Update: I found an old NpgSQL thread at https://github.com/npgsql/npgsql/issues/576 that discusses this issue in more detail. This thread suggests adding "UseSslStream=false" to the connection string. I tested this, and now NpgSQL 4.0.10 works with PostgreSQL 16.4. Unfortunately, I cannot control the connection string Power BI uses to connect to my PostgreSQL database, but I suppose recompiling NpgSQL 4.0.10 with that option disabled by default would work. I've read in a couple places that this issue only occurs when ssl_ca_file is set, and I can confirm that my PostgreSQL server has this. So configuring ssl_ca_file may be important for anyone wishing to reproduce the issue.

I don't know enough about TLS handshakes and session tickets to know where the bug truly lies (PostgreSQL/OpenSSL vs .NET's SslStream).

Cameron Vogt | Software Developer
Direct: 314-756-2302 | Cell: 636-388-2050
1585 Fencorp Drive | Fenton, MO 63026
Automatic Controls Equipment Systems, Inc.

  5. Re: TLS session tickets disabled?

    Jacob Champion <jacob.champion@enterprisedb.com> — 2024-08-15T17:52:32Z

    On Thu, Aug 15, 2024 at 10:36 AM Cameron Vogt
<cvogt@automaticcontrols.net> wrote:
> I don't know enough about TLS handshakes and session tickets to know where the bug truly lies (PostgreSQL/OpenSSL vs .NET's SslStream).

I'm getting the feeling that this is our bug, and that we should be
using both SSL_OP_NO_TICKET (for TLSv1.2) and SSL_CTX_set_num_tickets
(for TLSv1.3). I don't see any indication in the docs or source that
the latter does anything for 1.2.

(cc'ing Daniel)

--Jacob

  6. Re: TLS session tickets disabled?

    Daniel Gustafsson <daniel@yesql.se> — 2024-08-15T19:33:42Z

    > On 15 Aug 2024, at 19:52, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
> 
> On Thu, Aug 15, 2024 at 10:36 AM Cameron Vogt
> <cvogt@automaticcontrols.net> wrote:
>> I don't know enough about TLS handshakes and session tickets to know where the bug truly lies (PostgreSQL/OpenSSL vs .NET's SslStream).
> 
> I'm getting the feeling that this is our bug, and that we should be
> using both SSL_OP_NO_TICKET (for TLSv1.2) and SSL_CTX_set_num_tickets
> (for TLSv1.3). I don't see any indication in the docs or source that
> the latter does anything for 1.2.

Thanks for copying me, I have been on vacation and had missed this thread.  It
does indeed have the smell of me messing up when reading the OpenSSL docs =(

--
Daniel Gustafsson

  7. Re: TLS session tickets disabled?

    Daniel Gustafsson <daniel@yesql.se> — 2024-08-16T08:11:32Z

    > On 15 Aug 2024, at 21:33, Daniel Gustafsson <daniel@yesql.se> wrote:
> 
>> On 15 Aug 2024, at 19:52, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
>> 
>> On Thu, Aug 15, 2024 at 10:36 AM Cameron Vogt
>> <cvogt@automaticcontrols.net> wrote:
>>> I don't know enough about TLS handshakes and session tickets to know where the bug truly lies (PostgreSQL/OpenSSL vs .NET's SslStream).
>> 
>> I'm getting the feeling that this is our bug, and that we should be
>> using both SSL_OP_NO_TICKET (for TLSv1.2) and SSL_CTX_set_num_tickets
>> (for TLSv1.3). I don't see any indication in the docs or source that
>> the latter does anything for 1.2.
> 
> Thanks for copying me, I have been on vacation and had missed this thread.  It
> does indeed have the smell of me messing up when reading the OpenSSL docs =(

The attached, backpatched all the way, should be the correct fix.  Sorry for
the mess =(

--
Daniel Gustafsson

  8. Re: TLS session tickets disabled?

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-08-16T14:44:25Z

    Daniel Gustafsson <daniel@yesql.se> writes:
> On 15 Aug 2024, at 19:52, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
>>> I'm getting the feeling that this is our bug, and that we should be
>>> using both SSL_OP_NO_TICKET (for TLSv1.2) and SSL_CTX_set_num_tickets
>>> (for TLSv1.3). I don't see any indication in the docs or source that
>>> the latter does anything for 1.2.

> The attached, backpatched all the way, should be the correct fix.  Sorry for
> the mess =(

Can we verify that this fixes the originally-reported problem?

			regards, tom lane

  9. Re: TLS session tickets disabled?

    Cameron Vogt <cvogt@automaticcontrols.net> — 2024-08-16T19:11:53Z

    I can confirm the .diff patch Daniel sent over solves my issue. Here are the steps I took to verify:

I downloaded PostrgeSQL 16.4's source code and figured out how to compile it using the official documentation. I configured a new testing PostgreSQL server (built from the source) to mimic the configuration of my original database. Before implementing the patch, I verified that I still get the same issue when connecting via NpgSQL 4.0.10 to the source-built testing server. Then I implemented the patch, recompiled everything, and I verified that the issue is now gone when connecting via NpgSQL 4.0.10.

Thank you!

Cameron Vogt | Software Developer
Direct: 314-756-2302 | Cell: 636-388-2050
1585 Fencorp Drive | Fenton, MO 63026
Automatic Controls Equipment Systems, Inc.

  10. Re: TLS session tickets disabled?

    Jacob Champion <jacob.champion@enterprisedb.com> — 2024-08-16T23:00:26Z

    On Fri, Aug 16, 2024 at 12:12 PM Cameron Vogt
<cvogt@automaticcontrols.net> wrote:
>
> I can confirm the .diff patch Daniel sent over solves my issue.

I also tested against a Python stack that's session-aware and was
producing the same error message, and the patch fixes it.

Thanks!
--Jacob

  11. Re: TLS session tickets disabled?

    Daniel Gustafsson <daniel@yesql.se> — 2024-08-17T21:27:43Z

    > On 17 Aug 2024, at 01:00, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
> 
> On Fri, Aug 16, 2024 at 12:12 PM Cameron Vogt
> <cvogt@automaticcontrols.net> wrote:
>> 
>> I can confirm the .diff patch Daniel sent over solves my issue.
> 
> I also tested against a Python stack that's session-aware and was
> producing the same error message, and the patch fixes it.

Thanks for confirming, once I have better access to my laptop (should be
tomorrow Sunday or Monday at the latest) I'll get this committed and
backpatched.

--
Daniel Gustafsson

  12. Re: TLS session tickets disabled?

    Daniel Gustafsson <daniel@yesql.se> — 2024-08-19T12:52:45Z

    > On 17 Aug 2024, at 23:27, Daniel Gustafsson <daniel@yesql.se> wrote:
> 
>> On 17 Aug 2024, at 01:00, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
>> 
>> On Fri, Aug 16, 2024 at 12:12 PM Cameron Vogt
>> <cvogt@automaticcontrols.net> wrote:
>>> 
>>> I can confirm the .diff patch Daniel sent over solves my issue.
>> 
>> I also tested against a Python stack that's session-aware and was
>> producing the same error message, and the patch fixes it.
> 
> Thanks for confirming, once I have better access to my laptop (should be
> tomorrow Sunday or Monday at the latest) I'll get this committed and
> backpatched.

This has now been done.

--
Daniel Gustafsson