On Wed, Sep 18, 2024 at 02:02:32PM +0200, Geert Hendrickx wrote:
> > > > warning: ignoring unknown key exchange group "x25519_kyber768"
> >
> > What Postfix process is logging this?
>
> smtpd, as soon as I connect to port 25 (ie., as soon as smtpd is started
> and reads this config). It gets logged twice at the same time, strangely.
> [...]
> > and ultimately make sure that your smtp(8) and/or smtpd(8) processes are
> > not chrooted, lest that get in the way of loading the provider.
>
> Not chrooted. Both strace and lsof confirm that the oqsprovider.so module
> is being linked by smtpd (and later handed over to tlsmgr).
For the moment, I'll accept it is loading the provider and likely
unchrooted.
> > > Looking at the code in src/tls/tls_dh.c, Postfix verifies each group name
> > > in tls_eecdh_auto_curves and tls_ffdhe_auto_groups with OBJ_sn2nid(3),
> >
> > And then tries to use the group in a throw-away SSL_CTX, but I guess
> > that would not log the above warning:
> >
> > int nid = EC_curve_nist2nid(group);
> >
> > if (nid == NID_undef)
> > nid = OBJ_sn2nid(group);
> > if (nid == NID_undef)
> > nid = OBJ_ln2nid(group);
> > if (nid == NID_undef) {
> > msg_warn("ignoring unknown key exchange group \"%s\"", group);
> > continue;
> > }
>
> Indeed it already fails at one of the *2nid calls. nginx uses only
> OBJ_sn2nid:
>
> https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L1540
Well, if OBJ_sn2nid(group) had succeeded, the message would not have
been logged, so clearly with the OpenSSL library used in your Postfix
build, neither OBJ_sn2nid() nor OBJ_ln2nid() are able to find this
group. That's the only way that message would be logged.
This isn't surprising, since
$ git grep -i x25519_kyber768 origin/openssl-3.3
returns no output. The OBJ_sn2nid() function is not extensible, and not
affected by loading of providers. To actually be able to map this
algorithm to a "nid", the base OpenSSL code would have to know about
"x25519_kyber768".
> with success on the exact same group list.
That's because nginx must not solely rely on OBJ_sn2nid for these
groups. In OpenSSL 3.x with "providers" the list of supported
groups can be extended, with the provider returning a list of
TLS_GROUP_INFO structures:
typedef struct tls_group_info_st {
char *tlsname; /* Curve Name as in TLS specs */
char *realname; /* Curve Name according to provider */
char *algorithm; /* Algorithm name to fetch */
unsigned int secbits; /* Bits of security (from SP800-57) */
uint16_t group_id; /* Group ID */
int mintls; /* Minimum TLS version, -1 unsupported */
int maxtls; /* Maximum TLS version (or 0 for undefined) */
int mindtls; /* Minimum DTLS version, -1 unsupported */
int maxdtls; /* Maximum DTLS version (or 0 for undefined) */
char is_kem; /* Mode for this Group: 0 is KEX, 1 is KEM */
} TLS_GROUP_INFO;
Which are saved in the SSL_CTX, and used to resolved group names passed
to SSL_CTX_set1_groups_list(3). The Postfix TLS code evolved primarily
along with OpenSSL 0.9.8, 1.0.x and 1.1.1, and has not changed much with
OpenSSL 3.0, beyond some bitrot fixes. Support for provider-based
signature schemes was not one of the changes.
The code would have to be changed to bypass "nids" (which are for
built-in algorithms only), and use the group name (be it slightly less
efficient).
And then call not SSL_CTX_set1_curves(), but rather
SSL_CTX_set1_curves_list(), after using the same API on a throw-away
SSL_CTX to check each desired element.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
