# hp Java TLS verification-token review

Pure Java accepted unknown verification strings as chain-only policies. Literal
`default` behaved the same way instead of retaining hostname verification. Both
could accept a trusted certificate for the wrong host. Settings construction now
normalizes supported tokens and rejects unknown ones before engine selection.
No TLS I/O hot-path code, locks, NIC configuration or published timings changed.

## Confirmed failure and scope

At `0ff348a4a9335a1e0f96fa612e7c6b0c62647d54`, a standalone JSSE reproduction
compiled the current `SessionSettings` and context-factory sources. It generated
a loopback certificate and explicitly trusted it, while expecting `wrong.invalid`.
HOST mode refused the handshake; unknown mode `strict` completed it. The helper
used the repository's actual SSLEngine handshake driver, not a mocked verifier.

The string builder and QuickFIX-style configuration loader preserved unknown
values. `PureJavaSslContextFactory` enabled chain trust for everything except
NONE but installed endpoint identification only for HOST. Literal `default` was
therefore not equivalent to the typed DEFAULT, whose token is empty. The new
real-handshake regression confirmed that literal `default` accepted a trusted
wrong-host certificate before this fix. Without a CA it also bypassed the
settings guard for an implicit insecure initiator configuration; the repro did
not establish a public-CA wrong-host attack, so that wider consequence is not
claimed as driven evidence.

This is independently confirmed in pure Java. The accompanying
[C++ review](RECORD_2026-10-02_hp-tls-verify-mode-review.md) covers the numeric-mode
guard in the common native transport. The Java fix protects both pure and JNI
engines at their shared settings boundary. It does not establish an equivalent
wrong-host bypass in Rust or pure .NET, which need separate evidence.

## Repair and regression checks

Settings now expose canonical `none`, `peer`, `host` or an empty default token.
The native parser's aliases `off`, `chain`, `hostname` normalize to their
canonical policy. Literal `default` normalizes to the existing empty default,
so an initiator still needs a CA or a deliberate NONE opt-out. Case conversion
uses `Locale.ROOT`; a Turkish process locale no longer alters `CHAIN` into an
unknown policy. The typed enum parser's documented fallback behavior is unchanged.

At `79f23a6a3e65b43aedf589b1553ec4cbb2980ca3` with just the test edits,
26 tests ran and all six new methods failed. They cover unknown builder tokens
with TLS enabled and disabled, unknown file-configured tokens, canonical modes
and aliases, explicit default without a CA, Turkish-locale handling, and an
actual wrong-host handshake under literal default. With the source fix, all 26
passed in the focused standalone run.

The broader Maven run then passed 162 tests across eight suites with zero skips,
errors or failures: settings validation (16), settings (103), context factory
(10), channel (13), Java/JNI TLS parity (16), native TLS loopback (2), concurrent
native TLS configuration isolation (1), and required native loading (1).
JNI was rebuilt with GCC 14, optimization/LTO, both bypass providers and OpenSSL;
its SHA-256 is `1d3fddccd623da8e05021e4fbb6856655b6414780e0bce6abba933ddbeac6053`.
All three changed Java files passed public-export scanning with zero findings.

The run held an isolated-CPU lease while shared-core conformance work continued.
The existing idle-allocation checks reported zero bytes over 10,000 warmed polls.
These are functional and allocation checks, not comparative latency or physical
NIC measurements. The build was profile-free; it is not a replacement tuned matrix.

## Evidence and pending work

`~/archive/libhft/java-tls-verify-mode-review-20261002/` retains the original
standalone reproduction, its failing log, failing-before suite log, passing
script/log, selected fresh Maven reports, exact patch and source hashes.
Builds and temporary fixtures stayed under the session build root.

The independent .NET completed-read and nullable-FAST-maximum fixes remain held
by the repository restructuring claim. The managed staging manifest remains
withdrawn; rebuilding JNI alone does not approve an older combined bundle for
installation or establish refreshed managed physical-NIC coverage. The full
multi-flavour review remains ongoing.