Gate secp192r1/P-192 TLS-GROUP advertisement on curve availability

[yosuke-wolfssl]

Gate secp192r1/P-192 TLS-GROUP advertisement on curve availability

Fixes finding f_6497.

Problem

When libssl queries wolfProvider for TLS-GROUP capabilities,
wp_tls_group_capability() walked wp_param_group_list[] and
unconditionally advertised secp192r1 and P-192. That entry declares
only 80 bits of security, which is below the 112-bit modern/NIST minimum
and below the P-224 floor used by wolfCrypt FIPS.

Two consequences followed:

1. FIPS builds. P-192 is not a FIPS approved curve, and wolfCrypt FIPS
   blocks P-192 private key operations (WP_FIPS_CHECK_P192). The provider
   advertised it anyway, so libssl could select a group the underlying
   wolfCrypt cannot perform, failing at key generation rather than at
   negotiation. The brainpool curves in the same table were already gated
   with #ifndef HAVE_FIPS, so the intent to FIPS-gate non-approved curves
   was established; P-192 was simply missed.
2. Curve not compiled in. Nothing tied the entry to whether secp192r1
   was actually built into wolfCrypt, so the provider could advertise a
   curve it cannot satisfy.

A peer configured to accept the advertised set could therefore negotiate an
80-bit ECDHE group with no error surfaced to the application.

Fix

Wrap the two P-192 entries in the curve's own availability macro, plus an
explicit FIPS exclusion:

static const OSSL_PARAM wp_param_group_list[][11] = {
#if defined(WP_HAVE_EC_P192) && !defined(HAVE_FIPS)
    WP_TLS_GROUP_ENTRY_EC(    "secp192r1"      , "prime192v1"     , 0 ),
    WP_TLS_GROUP_ENTRY_EC(    "P-192"          , "prime192v1"     , 0 ),
#endif
    WP_TLS_GROUP_ENTRY_EC(    "secp224r1"      , "secp224r1"      , 1 ),

WP_HAVE_EC_P192 already exists in include/wolfprovider/settings.h and is
defined as (HAVE_ECC192 || HAVE_ALL_CURVES) && ECC_MIN_KEY_SZ <= 192. It
covers the "curve compiled in and usable" half, including hardened builds
that raise the minimum ECC key size.

Both terms are needed. ECC_MIN_KEY_SZ defaults to 224 in a plain non-FIPS
build, so WP_HAVE_EC_P192 is already off by default there. However,
wolfSSL defaults ECC_MIN_KEY_SZ to 192 under FIPS_VERSION_GE(2,0),
so a FIPS build that does not separately override it would leave
WP_HAVE_EC_P192 defined. The explicit !defined(HAVE_FIPS) term
guarantees P-192 is never advertised in a FIPS build regardless of the
configured minimum key size, and matches the existing brainpool gating
convention in the same file.

Scope

This change is intentionally limited to P-192, the subject of the finding.
The P-224, P-256, P-384, and P-521 entries remain unconditional even
though each has a corresponding WP_HAVE_EC_Pxxx macro. Those curves all
meet the 112-bit floor and are FIPS approved. Gating them on their
availability macros is a pre-existing inconsistency and is left as a
separate follow-up rather than widening this fix.

Testing

New regression test test_ec_tls_group_p192 in test/test_ecc.c (registered
in test/unit.c and test/unit.h). It calls
OSSL_PROVIDER_get_capabilities(prov, "TLS-GROUP", ...), walks the advertised
group list, and asserts that P-192 presence matches the guard, so it stays
correct in both FIPS and non-FIPS builds.

Verified at runtime against the actual built provider across three
configurations:

Configuration	secp192r1 / P-192 advertised
Guarded, WP_HAVE_EC_P192 on, non-FIPS	Yes (correct, curve is usable)
Guarded, WP_HAVE_EC_P192 forced off	No (P-224 and above unaffected)
Guarded, HAVE_FIPS forced on	No (P-224 and above unaffected)
Unguarded, WP_HAVE_EC_P192 off (pre-fix)	Yes (reproduces the bug)

The last row is the negative control: it confirms the test fails without the
fix rather than passing vacuously.

[Copilot]

Pull request overview

This pull request prevents wolfProvider from advertising the weak/non-FIPS P-192 (secp192r1) TLS group unless the curve is both compiled/usable and the build is non-FIPS, avoiding negotiation of unsupported or too-weak groups and aligning advertised capabilities with actual provider behavior.

Changes:

• Gate secp192r1 / P-192 TLS-GROUP capability advertisement behind WP_HAVE_EC_P192 and !HAVE_FIPS.
• Add a regression test that enumerates TLS-GROUP capabilities and asserts P-192 presence/absence matches the same compile-time guard.
• Register the new test in the unit test harness.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/wp_tls_capa.c	Conditionally excludes P-192 TLS group entries from the advertised capability list in FIPS or when the curve isn’t available.
test/test_ecc.c	Adds a capability-walk test validating whether P-192 is advertised matches build-time gating.
test/unit.c	Registers the new ECC TLS-GROUP advertisement test when ECC is enabled.
test/unit.h	Declares the new unit test entry point.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #432

Scan targets checked: wolfprovider-bugs, wolfprovider-src

No new issues found in the changed files. ✅

[aidangarske]

🐺 Skoll Code Review

Overall recommendation: REQUEST_CHANGES
Findings: 1 total — 1 posted, 0 skipped

Posted findings

• [High] HAVE_FIPS_VERSION builds can still advertise P-192 — src/wp_tls_capa.c:138, test/test_ecc.c:2913

Review generated by Skoll.

[aidangarske]

🟠 [High] HAVE_FIPS_VERSION builds can still advertise P-192
🚫 BLOCK bug

The PR gates the P-192 TLS-GROUP entries with !defined(HAVE_FIPS), and the new regression test uses the same condition. Existing FIPS handling in this repo treats defined(HAVE_FIPS) || defined(HAVE_FIPS_VERSION) as enabling FIPS P-192 restrictions, for example include/wolfprovider/wp_fips.h includes WP_FIPS_CHECK_P192 in the default mask under either macro, and existing ECC tests expect P-192 private operations to fail under either macro. In a wolfSSL FIPS build that defines HAVE_FIPS_VERSION without HAVE_FIPS, WP_HAVE_EC_P192 may still be true, so this PR would continue advertising secp192r1 and P-192 while wolfProvider's FIPS checks reject P-192 private operations. The new test would also expect advertisement in that configuration, so it would not catch the regression.

Recommendation: Update both the capability table guard and the test expectation to exclude HAVE_FIPS_VERSION builds as well as HAVE_FIPS builds. Use the same FIPS predicate as the P-192 runtime checks and existing ECC tests, and mirror it in the regression test:

#if defined(WP_HAVE_EC_P192) && !defined(HAVE_FIPS) &&
!defined(HAVE_FIPS_VERSION)
WP_TLS_GROUP_ENTRY_EC( "secp192r1" , "prime192v1" , 0 ),
WP_TLS_GROUP_ENTRY_EC( "P-192" , "prime192v1" , 0 ),
#endif