# hp C++ TLS verification-mode review

An unknown numeric client verification mode silently selected chain-only checks.
With a trusted CA, the C++ transport accepted a certificate for the wrong host.
Client setup now refuses unknown modes before creating a TLS context or opening
the connection. This changes cold configuration handling only: no send/receive
hot-path code, locks, NIC configuration or published latency results changed.

## Confirmed scope and repair

At `273b2da9a6394ed78b4e464bff1093b3839f8d0f`, the standalone loopback
reproducer generated a CA and a server certificate whose SAN was `127.0.0.1`.
The client expected `wrong.example`. Explicit HOST mode refused the handshake;
mode `99` accepted it. The same reproducer refuses both after the fix.

`FixSocketSslConfig::SetVerify(int, ...)` permits arbitrary integers. Previously,
`PrepareClient` enabled chain verification for every value other than NONE,
but installed the hostname check only for HOST. Consequently an unknown value
with a valid CA was treated like an intentional PEER policy. The guard now
requires NONE, PEER or HOST after resolving DEFAULT. DEFAULT still means HOST
and a missing CA still fails closed. Stale comments describing the former
empty-CA downgrade were corrected.

This is a programmatic-configuration defect, not a bypass of the normal string
settings parser: that parser already rejects unknown tokens. The certificate
chain must still be trusted for the demonstrated wrong-host acceptance. The fix
does not change intentional PEER or NONE policies. This run tested C++ only;
other flavours must not be included in its finding by assumption. Native bridges
inherit the guard when rebuilt, but this run did not rebuild those bridges.
A subsequent [Java review](RECORD_2026-10-02_hp-java-tls-verify-mode-review.md)
independently confirmed string-token downgrades and rebuilt/validated JNI.

## Regression evidence

At `0538fb33a9c6b724d4cf21177c16828647f40406` with only the new test edits,
the verification suite exited 1 with 20 failed checks. Five invalid values
(`-1`, `4`, `99`, `INT_MIN`, `INT_MAX`) each accepted matching-host and wrong-host
connections with a trusted CA. The empty-CA cases already failed. After the
source fix, all fifteen combinations refuse the connection and leave the
socket, SSL and context handles empty. The same client then connects successfully
after correction to HOST mode. Test PEM fixtures now follow the portable
temporary-directory helper and fail clearly if their temporary file cannot be
created.

The passing run rebuilt and ran five suites with GCC 14, optimization and LTO:
`test_fix_ssl_verify`, `test_fix_ssl_ownership`, `test_fix_ssl_stress`,
`test_fix_reconnect_realsocket` and `test_fix_send_deadline`.
Verification passed 72 checks, including the existing HOST/PEER/NONE, mutual-TLS,
identity-failure and cipher-policy checks. Backpressure delivered all 60 messages
intact and in order, with 59 WANT_WRITE retries. The full verification test also
passed Clang 21 AddressSanitizer and UndefinedBehaviorSanitizer with leak
detection enabled. No test reported a skip. Both changed engine files passed
public-export scanning with zero findings.

These functional checks held an isolated-CPU lease while another session used
shared CPUs. They are neither whole-host-quiet latency measurements nor physical
NIC tests; no timing improvement is claimed.

## Retained evidence and pending work

`~/archive/libhft/tls-verify-mode-review-20261002/` retains the standalone source,
red reproduction, failing-before suite log, passing script/log and exact patch.
The verified source hashes are:

- `FixSocketSsl.h`: `40b820437d59d190e3faa5fd40edda65fcd73e502d574e470c7d3c2df40d20ec`
- `test_fix_ssl_verify.cpp`: `5c8cd724b04d089bac6e3e986f609c1fd10ceec35e13ec93007a95583bd0dadf`

The .NET restructuring claim still blocks the independent completed-TLS-read
and nullable-FAST-maximum fixes. The managed staging manifest remains withdrawn:
this record does not approve the home installer to stage an older bundle or
establish refreshed managed physical-NIC coverage. The full review remains ongoing.