Add ssl_(supported|shared)_groups to sslinfo

On 19 Feb 2026, at 18:44, Dmitry Dolgov <9erthalion6@gmail.com> wrote:

I've been experimenting with ssl recently, and found it's useful to have
more information exposed via contrib/sslinfo, in particular
ssl_supported_groups and ssl_shared_groups to show TLS groups extension.

In general I'm not opposed to adding more information to sslinfo.

+PG_FUNCTION_INFO_V1(ssl_supported_groups);
+Datum
+ssl_supported_groups(PG_FUNCTION_ARGS)
The supported groups is sent as a TLS extension, and we already have
ssl_extension_info() for listing extension values.  Shouldn't this be a part of
that function for consistency?

--- /dev/null
+++ b/contrib/sslinfo/sslinfo--1.3.sql
@@ -0,0 +1,56 @@
+/* contrib/sslinfo/sslinfo--1.3.sql */
No need to spin a new 1.3 file, the upgrade file from 1.2 to 1.3 is sufficient
since the extension machinery will play the files in order to reach 1.3.

+CREATE FUNCTION ssl_shared_groups() RETURNS text
Why not return this as text[] rather than a delimited string?

The patch also lacks docs updates for the new functions.

--
Daniel Gustafsson

On Mon, Feb 23, 2026 at 03:32:02PM +0100, Daniel Gustafsson wrote:
+PG_FUNCTION_INFO_V1(ssl_supported_groups);
+Datum
+ssl_supported_groups(PG_FUNCTION_ARGS)
The supported groups is sent as a TLS extension, and we already have
ssl_extension_info() for listing extension values.  Shouldn't this be a part of
that function for consistency?

Good point, thanks. I'll move the functionality in there.

--- /dev/null
+++ b/contrib/sslinfo/sslinfo--1.3.sql
@@ -0,0 +1,56 @@
+/* contrib/sslinfo/sslinfo--1.3.sql */
No need to spin a new 1.3 file, the upgrade file from 1.2 to 1.3 is sufficient
since the extension machinery will play the files in order to reach 1.3.

+CREATE FUNCTION ssl_shared_groups() RETURNS text
Why not return this as text[] rather than a delimited string?

No particular reason, but I see the point -- going to change it to text[].

On Mon, Feb 23, 2026 at 6:32 AM Daniel Gustafsson <daniel@yesql.se> wrote:

+CREATE FUNCTION ssl_shared_groups() RETURNS text

I don't feel strongly about this, so feel free to disregard: Is there
a reason this API is focusing on the shared group list as opposed to
the actual negotiated group in use? The latter seems more widely
useful to me, and it'd match up with ssl_cipher(). (Or maybe we
already have the negotiated group somewhere and I just never noticed?)

--Jacob

On Mon, Feb 23, 2026 at 08:48:02AM -0800, Jacob Champion wrote:
On Mon, Feb 23, 2026 at 6:32 AM Daniel Gustafsson <daniel@yesql.se> wrote:

+CREATE FUNCTION ssl_shared_groups() RETURNS text

I don't feel strongly about this, so feel free to disregard: Is there
a reason this API is focusing on the shared group list as opposed to
the actual negotiated group in use? The latter seems more widely
useful to me, and it'd match up with ssl_cipher(). (Or maybe we
already have the negotiated group somewhere and I just never noticed?)

No deep reason, it was just useful for some particular experiments and
for gathering understanding of what's going on. Would you find it
reasonable to have both, shared groups and the negotiated group, or
having only the latter is strictly better?

On Mon, Feb 23, 2026 at 9:58 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:

No deep reason, it was just useful for some particular experiments and
for gathering understanding of what's going on. Would you find it
reasonable to have both, shared groups and the negotiated group, or
having only the latter is strictly better?

Well, take this with a grain of salt, because I tend to use tools
other than sslinfo for TLS debugging. But it seems to me that all of
the sslinfo functions cater to facts about the current connection: the
client certificate, the cipher, the protocol version.

These new functions instead focus on what *might* have been, which
makes them kind of awkward. Maybe sslinfo should be expanded to give
us those tools as well, but I wonder if handshake debugging might be a
better fit for some debug logging on the server side. Or if there
might be an overall feature here -- "why did the negotiation behave
this way?" -- that could be better served by something that's not a
new array of sslinfo functions that have to be correlated with each
other.

(Also, while I was taking a look at ssl_extension_info(), I realized
that it's focused on certificate extensions and not protocol
extensions. It's kind of unfortunately named.)

--Jacob

On Mon, Feb 23, 2026 at 11:22:22AM -0800, Jacob Champion wrote:
On Mon, Feb 23, 2026 at 9:58 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:

No deep reason, it was just useful for some particular experiments and
for gathering understanding of what's going on. Would you find it
reasonable to have both, shared groups and the negotiated group, or
having only the latter is strictly better?

Well, take this with a grain of salt, because I tend to use tools
other than sslinfo for TLS debugging. But it seems to me that all of
the sslinfo functions cater to facts about the current connection: the
client certificate, the cipher, the protocol version.

These new functions instead focus on what *might* have been, which
makes them kind of awkward. Maybe sslinfo should be expanded to give
us those tools as well, but I wonder if handshake debugging might be a
better fit for some debug logging on the server side. Or if there
might be an overall feature here -- "why did the negotiation behave
this way?" -- that could be better served by something that's not a
new array of sslinfo functions that have to be correlated with each
other.

I see what you mean, an interesting point. After some pondering and
looking at the history of sslinfo it looks like its purpose was already
extended once beyond what was originally intended. AFAICT the initial
implementation was concerning itself only with the information about SSL
certificates (surprisingly even now the extension comment and
documentation say "information about SSL certificates"), and now it also
features the current cipher and version. I take it as an argument that
expanding sslinfo goal and focus is not a problem, as long as it's
clearly communicated and documented. What do you think?

(Also, while I was taking a look at ssl_extension_info(), I realized
that it's focused on certificate extensions and not protocol
extensions. It's kind of unfortunately named.)

Yeah, that's unfortunate. I've ended up introducing a similarly looking
ssl_group_info, which returns a set of record representing groups.

On Fri, Feb 27, 2026 at 10:57 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:

I take it as an argument that
expanding sslinfo goal and focus is not a problem, as long as it's
clearly communicated and documented. What do you think?

Yeah -- as long as the API stays coherent, I have no issue with
expanding sslinfo's capabilities.

select * from ssl_group_info();
type | name
------------+--------------------
negotiated | X25519MLKEM768
shared | X25519MLKEM768
shared | x25519
supported | X25519MLKEM768
supported | x25519

Hmm, I'm developing strong opinions over something I said I didn't
feel strongly about. Sorry...

The type names "negotiated", "shared" and "supported" don't really
tell me much as an end user. I know, as a dev, that "negotiated" is
the one that was chosen, "supported" is what the client provided, and
"shared" is the intersection of the client and server sets. But I
think it'd be good to choose names that are either based on the
official TLS specification, or immediately clear to someone who is not
well-versed in TLS to begin with, as opposed to using OpenSSL's
internal API names.

Also, I feel like this is still missing the server side of the Venn diagram.

Also also: if we later expose a version of this table for the
ciphersuites or other negotiated parameters, is this how we'd want the
table to look? What did you care most about when you were debugging?

--Jacob

On Fri, Feb 27, 2026 at 04:51:40PM -0800, Jacob Champion wrote:

select * from ssl_group_info();
type | name
------------+--------------------
negotiated | X25519MLKEM768
shared | X25519MLKEM768
shared | x25519
supported | X25519MLKEM768
supported | x25519

Hmm, I'm developing strong opinions over something I said I didn't
feel strongly about. Sorry...

No worries, it's a valuable discussion so far :)

The type names "negotiated", "shared" and "supported" don't really
tell me much as an end user. I know, as a dev, that "negotiated" is
the one that was chosen, "supported" is what the client provided, and
"shared" is the intersection of the client and server sets. But I
think it'd be good to choose names that are either based on the
official TLS specification, or immediately clear to someone who is not
well-versed in TLS to begin with, as opposed to using OpenSSL's
internal API names.

Naming is hard of course, but my plan was to stick to short names like
those above, and unwrap them in the documentation:

* Supported: list of named groups supported by the client for key
exchange in the form of "supported_groups" extension.

Supported group is the exact terminology used in the TLS spec.

* Shared: lisf of named groups shared with the server side.

This one actually doesn't appear in the spec. The closest name
featured is "selected_groups", but only in the context of the retry
requests. Thus I took this form the OpenSSL docs.

* Negotiated: the group used for the handshake key exchange process.

Surprsingly, I don't see any exact terminology for this in the TLS
spec, it just says "the named group for the key being exchanged". The
name is taken from the OpenSSL documentation.

How does it sound?

Also, I feel like this is still missing the server side of the Venn diagram.

Indeed, the TLS spec says that the server is permitted to send the
"supported_groups" extension to the client, so this might be
interesting. But it doesn't look like there is any OpenSSL API to get
those, beyond SSL_ctrl, which is not supposed to be called directly.

Also also: if we later expose a version of this table for the
ciphersuites or other negotiated parameters, is this how we'd want the
table to look? What did you care most about when you were debugging?

I don't see why not. The reason why I've started tinkering on that was
only to get the negotiated group. But I'm convinced that, since
PostgreSQL sets the groups extension, it totally makes sense to provide
some API for diagnostig reasons to check what's in there beyond only one
single group.

On Tue, Mar 03, 2026 at 11:43:10AM +0100, Dmitry Dolgov wrote:
Naming is hard of course, but my plan was to stick to short names like
those above, and unwrap them in the documentation:

* Supported: list of named groups supported by the client for key
exchange in the form of "supported_groups" extension.

Supported group is the exact terminology used in the TLS spec.

* Shared: lisf of named groups shared with the server side.

This one actually doesn't appear in the spec. The closest name
featured is "selected_groups", but only in the context of the retry
requests. Thus I took this form the OpenSSL docs.

* Negotiated: the group used for the handshake key exchange process.

Surprsingly, I don't see any exact terminology for this in the TLS
spec, it just says "the named group for the key being exchanged". The
name is taken from the OpenSSL documentation.

How does it sound?

Added those into the documentation, will create a CF item.