nx_tls13_ch_compat_test.nx

nx_tls13_ch_compat_test.nx -- B2-HTTPBIN-CH gate row (browser arc). The B2 defect was "httpbin.org answers our ClientHello with an alert". ROOT CAUSE (oracle-measured 2026-06-10, openssl census): httpbin.org does NOT speak TLS 1.3 at all (-tls1_3 -> no cipher; -tls1_2 -> ECDHE-RSA-AES128-GCM-SHA256, P-256 temp key). Its ELB answers a 1.3-only CH with warning close_notify (AL=1 AD=0). Our CH was never malformed -- the CH-compat suspicion is REFUTED. TLS 1.2 client support = separate named rung (not B2's bar). So this row proves the CH-compat claim with two live legs: LEG A (httpbin census, live-updating): send the PRODUCT dual- share CH to httpbin.org and classify the response: - warning/any close_notify (AD=0) or protocol_version (AD=70) alert, or a TLS 1.2 ServerHello (no supported_versions ext) -> the measured TLS-1.2-only signature -> leg PASS - a TLS 1.3 ServerHello -> httpbin enabled 1.3: the leg now DEMANDS the full handshake to WAIT_CLIENT_FIN - any other alert (decode_error 50, illegal_parameter 47, handshake_failure 40) -> a REAL CH problem -> leg FAIL LEG B (P-256 live proof): secp256r1-ONLY CH to github.com (census: completes TLS 1.3 + P-256 + TLS_AES_128_GCM_SHA256). Server MUST take our P-256 share (GR=23 asserted) and the FULL encrypted handshake walks to WAIT_CLIENT_FIN -- the live E2E proof of rung B4's path against an independent implementation, which dual-share connects can never exercise (servers prefer x25519 when offered). Exit 0 iff BOTH legs pass. Markers: L1=/L2= leg verdicts, AL=/AD= alert level/desc, CS=/GR= server cipher + group pick, RC=/CT=/DV=/MT=/DW=/ST= per-record walk (B1 probe pattern). Prereq: /tmp/mozilla_certdata.txt staged (gate self-stages). expect_exit: 0 license_tier: ORIGINAL