pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedTLS session tickets disabled?
13+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2024-08-19 4fdb6558c2 cd98a142cb f925b7f65d 19021d28cd 9333174af4 23c200940e 8cea8c023e Fix regression in TLS session ticket disabling
* TLS session tickets disabled?
@ 2024-08-12 21:19 Cameron Vogt <cvogt@automaticcontrols.net>
0 siblings, 1 reply; 13+ messages in thread
From: Cameron Vogt @ 2024-08-12 21:19 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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.gma....
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.+Fent...;
<https://www.google.com/maps/dir/38.5384448,-90.43968/Automatic+Controls+Equipment+Systems,+Inc.+Fent..., Missouri 63026<https://www.google.com/maps/dir/38.5384448,-90.43968/Automatic+Controls+Equipment+Systems,+Inc.+Fent...;
[cid:aces_66e9dd1e-ddf8-4d47-aa75-b72eea6ea7eb.png]
[cid:supportlink_28817f99-b936-4867-8557-910a1c601d21.png]<https://automaticcontrols.net/request-support/;
Attachments:
aces_66e9dd1e-ddf8-4d47-aa75-b72eea6ea7eb.png (image/png, 297.0K) download
view image
supportlink_28817f99-b936-4867-8557-910a1c601d21.png (image/png, 3.8K) download
view image
* Re: TLS session tickets disabled?
@ 2024-08-13 18:05 Tom Lane <tgl@sss.pgh.pa.us>
parent: Cameron Vogt <cvogt@automaticcontrols.net>
0 siblings, 1 reply; 13+ messages in thread
From: Tom Lane @ 2024-08-13 18:05 UTC (permalink / raw)
To: Cameron Vogt <cvogt@automaticcontrols.net>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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.gma....
> 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
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-13 20:59 Cameron Vogt <cvogt@automaticcontrols.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 13+ messages in thread
From: Cameron Vogt @ 2024-08-13 20:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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-2Dc....
> 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
Attachments:
powerbi_client_error.log (application/octet-stream, 2.5K) download
minimal_test.cs (text/plain, 311B) download
using Npgsql;
var connectionString = "Host=HOST;Port=PORT;Username=USERNAME;Password=PASSWORD;Database=DATABASE;SSL Mode=Require";
await using var conn = new NpgsqlConnection(connectionString);
await conn.OpenAsync();
await using var conn2 = new NpgsqlConnection(connectionString);
await conn2.OpenAsync();
* Re: TLS session tickets disabled?
@ 2024-08-14 21:59 Cameron Vogt <cvogt@automaticcontrols.net>
parent: Cameron Vogt <cvogt@automaticcontrols.net>
0 siblings, 1 reply; 13+ messages in thread
From: Cameron Vogt @ 2024-08-14 21:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-15 17:52 Jacob Champion <jacob.champion@enterprisedb.com>
parent: Cameron Vogt <cvogt@automaticcontrols.net>
0 siblings, 1 reply; 13+ messages in thread
From: Jacob Champion @ 2024-08-15 17:52 UTC (permalink / raw)
To: Cameron Vogt <cvogt@automaticcontrols.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>; Daniel Gustafsson <daniel@yesql.se>
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
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-15 19:33 Daniel Gustafsson <daniel@yesql.se>
parent: Jacob Champion <jacob.champion@enterprisedb.com>
0 siblings, 1 reply; 13+ messages in thread
From: Daniel Gustafsson @ 2024-08-15 19:33 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Cameron Vogt <cvogt@automaticcontrols.net>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
> 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
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-16 07:49 Fire Emerald <fire.github@gmail.com>
0 siblings, 0 replies; 13+ messages in thread
From: Fire Emerald @ 2024-08-16 07:49 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: jacob.champion@enterprisedb.com, cvogt@automaticcontrols.net, Tom Lane <tgl@sss.pgh.pa.us>
> I recently updated one of my PostgreSQL databases to 16.4. Since
updating, (...) The error message in my PostgreSQL server's log file is
"could not accept SSL connection: session id context uninitialized".
I also updated my server from 16.3 > 16.4, nothing else changed and got
exactly the same error. I'm also using SSL, as well as Npgsql in
its current version v8.0.3 with VerifyFull including a CA file on server
side.
Something is broken in PostgreSQL 16.4.
The debug5 log shows for me that the first connection is established
successful, the second fails, hope it is okay to post this whole output
here, perhaps it helps to fix it soon:
2024-08-15 13:24:33.298 CEST [1] DEBUG: forked new backend, pid=37
socket=11
2024-08-15 13:24:33.299 CEST [37] LOG: connection received:
host=192.168.0.24 port=40653
2024-08-15 13:24:33.305 CEST [37] DEBUG: SSL: handshake start: "before SSL
initialization"
2024-08-15 13:24:33.305 CEST [37] DEBUG: SSL: accept loop: "before SSL
initialization"
2024-08-15 13:24:33.305 CEST [37] DEBUG: SSL: accept exit (-1): "before
SSL initialization"
2024-08-15 13:24:33.393 CEST [37] DEBUG: SSL: accept loop: "before SSL
initialization"
2024-08-15 13:24:33.393 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS read
client hello"
2024-08-15 13:24:33.393 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write server hello"
2024-08-15 13:24:33.393 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write certificate"
2024-08-15 13:24:33.395 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write key exchange"
2024-08-15 13:24:33.395 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write certificate request"
2024-08-15 13:24:33.395 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write server done"
2024-08-15 13:24:33.395 CEST [37] DEBUG: SSL: accept exit (-1): "SSLv3/TLS
write server done"
2024-08-15 13:24:33.419 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write server done"
2024-08-15 13:24:33.420 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS read
client certificate"
2024-08-15 13:24:33.421 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS read
client key exchange"
2024-08-15 13:24:33.421 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS read
certificate verify"
2024-08-15 13:24:33.421 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS read
change cipher spec"
2024-08-15 13:24:33.421 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS read
finished"
2024-08-15 13:24:33.421 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write session ticket"
2024-08-15 13:24:33.421 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write change cipher spec"
2024-08-15 13:24:33.422 CEST [37] DEBUG: SSL: accept loop: "SSLv3/TLS
write finished"
2024-08-15 13:24:33.422 CEST [37] DEBUG: SSL: handshake done: "SSL
negotiation finished successfully"
2024-08-15 13:24:33.422 CEST [37] DEBUG: SSL: accept exit (1): "SSL
negotiation finished successfully"
2024-08-15 13:24:33.422 CEST [37] DEBUG: SSL connection from
DN:"CN=rw_user" CN:"rw_user"
2024-08-15 13:24:33.432 CEST [37] DEBUG: InitPostgres
2024-08-15 13:24:33.432 CEST [37] DEBUG: my backend ID is 3
2024-08-15 13:24:33.433 CEST [37] DEBUG: StartTransaction(1) name:
unnamed; blockState: DEFAULT; state: INPROGRESS, xid/subid/cid: 0/1/0
2024-08-15 13:24:33.433 CEST [37] LOG: connection authenticated:
identity="CN=rw_user" method=cert
(/etc/postgresql/config/pg_hba.test.conf:130)
2024-08-15 13:24:33.433 CEST [37] LOG: connection authorized: user=rw_user
database=somedb SSL enabled (protocol=TLSv1.2,
cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256)
2024-08-15 13:24:33.434 CEST [37] DEBUG: CommitTransaction(1) name:
unnamed; blockState: STARTED; state: INPROGRESS, xid/subid/cid: 0/1/0
2024-08-15 13:24:33.457 CEST [37] DEBUG: StartTransaction(1) name:
unnamed; blockState: DEFAULT; state: INPROGRESS, xid/subid/cid: 0/1/0
2024-08-15 13:24:33.467 CEST [37] DEBUG: CommitTransaction(1) name:
unnamed; blockState: STARTED; state: INPROGRESS, xid/subid/cid: 0/1/0
2024-08-15 13:24:33.479 CEST [37] DEBUG: shmem_exit(0): 4
before_shmem_exit callbacks to make
2024-08-15 13:24:33.480 CEST [37] DEBUG: shmem_exit(0): 6 on_shmem_exit
callbacks to make
2024-08-15 13:24:33.480 CEST [37] DEBUG: proc_exit(0): 3 callbacks to make
2024-08-15 13:24:33.480 CEST [37] LOG: disconnection: session time:
0:00:00.180 user=rw_user database=somedb host=192.168.0.24 port=40653
2024-08-15 13:24:33.480 CEST [37] DEBUG: SSL: write alert (0x0100): "SSL
negotiation finished successfully"
2024-08-15 13:24:33.480 CEST [37] DEBUG: exit(0)
2024-08-15 13:24:33.480 CEST [37] DEBUG: shmem_exit(-1): 0
before_shmem_exit callbacks to make
2024-08-15 13:24:33.480 CEST [37] DEBUG: shmem_exit(-1): 0 on_shmem_exit
callbacks to make
2024-08-15 13:24:33.480 CEST [37] DEBUG: proc_exit(-1): 0 callbacks to make
2024-08-15 13:24:33.483 CEST [1] DEBUG: reaping dead processes
2024-08-15 13:24:33.483 CEST [1] DEBUG: server process (PID 37) exited
with exit code 0
2024-08-15 13:24:33.495 CEST [1] DEBUG: forked new backend, pid=38
socket=11
2024-08-15 13:24:33.496 CEST [38] LOG: connection received:
host=192.168.0.24 port=40654
2024-08-15 13:24:33.496 CEST [38] DEBUG: SSL: handshake start: "before SSL
initialization"
2024-08-15 13:24:33.496 CEST [38] DEBUG: SSL: accept loop: "before SSL
initialization"
2024-08-15 13:24:33.496 CEST [38] DEBUG: SSL: accept exit (-1): "before
SSL initialization"
2024-08-15 13:24:33.543 CEST [38] DEBUG: SSL: accept loop: "before SSL
initialization"
2024-08-15 13:24:33.543 CEST [38] DEBUG: SSL: write alert (0x0250): "error"
2024-08-15 13:24:33.543 CEST [38] DEBUG: SSL: accept exit (-1): "error"
2024-08-15 13:24:33.543 CEST [38] LOG: could not accept SSL connection:
session id context uninitialized
2024-08-15 13:24:33.543 CEST [38] DEBUG: SSL connection from
DN:"(anonymous)" CN:"(anonymous)"
2024-08-15 13:24:33.543 CEST [38] DEBUG: shmem_exit(0): 0
before_shmem_exit callbacks to make
2024-08-15 13:24:33.543 CEST [38] DEBUG: shmem_exit(0): 0 on_shmem_exit
callbacks to make
2024-08-15 13:24:33.544 CEST [38] DEBUG: proc_exit(0): 1 callbacks to make
2024-08-15 13:24:33.544 CEST [38] DEBUG: exit(0)
2024-08-15 13:24:33.544 CEST [38] DEBUG: shmem_exit(-1): 0
before_shmem_exit callbacks to make
2024-08-15 13:24:33.544 CEST [38] DEBUG: shmem_exit(-1): 0 on_shmem_exit
callbacks to make
2024-08-15 13:24:33.544 CEST [38] DEBUG: proc_exit(-1): 0 callbacks to make
2024-08-15 13:24:33.546 CEST [1] DEBUG: reaping dead processes
2024-08-15 13:24:33.546 CEST [1] DEBUG: server process (PID 38) exited
with exit code 0
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-16 08:11 Daniel Gustafsson <daniel@yesql.se>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 13+ messages in thread
From: Daniel Gustafsson @ 2024-08-16 08:11 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Cameron Vogt <cvogt@automaticcontrols.net>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
> 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
Attachments:
fix.diff (application/octet-stream, 570B) download
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index 7e056abd5a..60cf5d16e7 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openssl.c
@@ -270,9 +270,8 @@ be_tls_init(bool isServerStart)
*/
#ifdef HAVE_SSL_CTX_SET_NUM_TICKETS
SSL_CTX_set_num_tickets(context, 0);
-#else
- SSL_CTX_set_options(context, SSL_OP_NO_TICKET);
#endif
+ SSL_CTX_set_options(context, SSL_OP_NO_TICKET);
/* disallow SSL session caching, too */
SSL_CTX_set_session_cache_mode(context, SSL_SESS_CACHE_OFF);
* Re: TLS session tickets disabled?
@ 2024-08-16 14:44 Tom Lane <tgl@sss.pgh.pa.us>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 1 reply; 13+ messages in thread
From: Tom Lane @ 2024-08-16 14:44 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>; Cameron Vogt <cvogt@automaticcontrols.net>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-16 19:11 Cameron Vogt <cvogt@automaticcontrols.net>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 13+ messages in thread
From: Cameron Vogt @ 2024-08-16 19:11 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Daniel Gustafsson <daniel@yesql.se>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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.
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-16 23:00 Jacob Champion <jacob.champion@enterprisedb.com>
parent: Cameron Vogt <cvogt@automaticcontrols.net>
0 siblings, 1 reply; 13+ messages in thread
From: Jacob Champion @ 2024-08-16 23:00 UTC (permalink / raw)
To: Cameron Vogt <cvogt@automaticcontrols.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Daniel Gustafsson <daniel@yesql.se>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-17 21:27 Daniel Gustafsson <daniel@yesql.se>
parent: Jacob Champion <jacob.champion@enterprisedb.com>
0 siblings, 1 reply; 13+ messages in thread
From: Daniel Gustafsson @ 2024-08-17 21:27 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Cameron Vogt <cvogt@automaticcontrols.net>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
> 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
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: TLS session tickets disabled?
@ 2024-08-19 12:52 Daniel Gustafsson <daniel@yesql.se>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 0 replies; 13+ messages in thread
From: Daniel Gustafsson @ 2024-08-19 12:52 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: Cameron Vogt <cvogt@automaticcontrols.net>; Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
> 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
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2024-08-19 12:52 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-08-12 21:19 TLS session tickets disabled? Cameron Vogt <cvogt@automaticcontrols.net>
2024-08-13 18:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-08-13 20:59 ` Cameron Vogt <cvogt@automaticcontrols.net>
2024-08-14 21:59 ` Cameron Vogt <cvogt@automaticcontrols.net>
2024-08-15 17:52 ` Jacob Champion <jacob.champion@enterprisedb.com>
2024-08-15 19:33 ` Daniel Gustafsson <daniel@yesql.se>
2024-08-16 08:11 ` Daniel Gustafsson <daniel@yesql.se>
2024-08-16 14:44 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-08-16 19:11 ` Cameron Vogt <cvogt@automaticcontrols.net>
2024-08-16 23:00 ` Jacob Champion <jacob.champion@enterprisedb.com>
2024-08-17 21:27 ` Daniel Gustafsson <daniel@yesql.se>
2024-08-19 12:52 ` Daniel Gustafsson <daniel@yesql.se>
2024-08-16 07:49 Re: TLS session tickets disabled? Fire Emerald <fire.github@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox