From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tls 1.3: sending multiple tickets |
Date: | 2024-07-26 18:29:49 |
Message-ID: | CA+Tgmobvh0kC5RjX+P5pX+S7REF8boCz2zgDAXd-G1kv+QyQzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 26, 2024 at 10:23 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> We turn off TLS session tickets for two reasons: a) we don't support TLS
> session resumption, and some resumption capable client libraries can experience
> connection failures if they try to use tickets received in the setup (Npgsql at
> least had this problem in the past); b) it's network overhead in the connection
> setup phase which doesn't give any value due to us not supporting their use.
>
> TLS tickets were disallowed in 2017 in 97d3a0b09 but as Andres found out,
> TLSv1.3 session tickets had a new API which we didn't call and thus issued
> tickets.
Thanks much for this explanation.
> > I don't doubt that you're doing the right thing here but it'd be nice
> > to document why it's the right thing someplace.
>
> I can add a summary of the above in the comment for future readers if you think
> that would be useful.
I think having (a) and (b) from above at the end of the "Disallow SSL
session tickets" comment would be helpful.
While I'm complaining, the bit about SSL renegotiation could use a
better comment, too. One of my chronic complaints about comments is
that they should say why we're doing things, not what we're doing. To
me, having a comment that says "Disallow SSL renegotiation" followed
immediately by SSL_CTX_set_options(context, SSL_OP_NO_RENEGOTIATION)
is a good example of what not to do, because, I mean, I can guess
without the comment what that does. Actually, that comment is quite
well-written in terms of explaining why we do it in different ways
depending on the OpenSSL version; it just fails to explain why it's
important in the first place. I'm pretty sure I know in that case that
there are CVEs about that topic, but that's just because I happen to
remember the mailing list discussion on it, and I don't think every
hacker is contractually required to remember that.
I don't want to sound like I'm giving orders and I think it's really
up to you how much effort you want to put in here, but I feel like any
place where we are doing X because of some property of a non-PG code
base with which a particular reader might not be familiar, we should
have a comment explaining why we're doing it. And especially if it's
security-relevant.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-07-26 18:39:23 | Re: optimizing pg_upgrade's once-in-each-database steps |
Previous Message | Fujii Masao | 2024-07-26 18:10:41 | Re: [Proposal] Add foreign-server health checks infrastructure |