Repository navigation
winrm-light 2/6: NTLM message encryption over HTTP (port encryption streams off CXF) #104
Description
Depends on #103.
WinRM over plain HTTP (5985, the common configuration) requires SPNEGO/NTLM session encryption: SOAP bodies sealed with RC4 keys derived from the NTLM session key, wrapped in multipart/encrypted with signed sequence numbers.
Scope
- Port the existing, battle-tested logic in
org.metricshub.winrm.service.client.encryption(EncryptAndSignOutputStream,DecryptAndVerifyInInterceptor,NtlmKeys,MD4, ...) from CXF interceptors/conduits to plain request/response stream wrappers in the light client. The crypto is already framework-agnostic; only the plumbing changes. - Key handoff from the NTLM authenticator (winrm-light 1/6: Framework-free WSMan core (templated envelopes, JDK HTTP, NTLM over HTTPS) #103) to the sealing layer.
- Careful sequence-number handling across retries on the affine connection.
Acceptance
- WQL + command execution against a real host over HTTP/5985 with NTLM (
AllowUnencrypted=false, the Windows default) — byte-compatible with what the CXF stack negotiates today.
🤖 Generated with Claude Code
Activity
bertysentry commentedon Jul 23, 2026
Delivered in #109 (branch `feature/winrm-light`). NTLM message encryption over plain HTTP is in `NtlmCrypto` (RC4 seal/sign + unseal/verify, `multipart/encrypted` framing, signed sequence numbers), ported from the existing `org.metricshub.winrm.service.client.encryption` logic with the CXF/Apache coupling stripped. Root-cause fix baked in: the NTLM domain must be uppercased before NTOWFv2 or the server-side seal mismatches (HTTP 400). Live-verified WQL + command over HTTP/5985 with `AllowUnencrypted=false` (the Windows default). Subsequent review rounds hardened it (reject unencrypted responses after auth, serialize the connection, stale-connection detection, US-ASCII protocol constants).
🤖 Generated with Claude Code