Re: Add ssl_(supported|shared)_groups to sslinfo

> 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(at)gmail(dot)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.