OpenNHP/opennhp is a Go implementation of the Cloud Security Alliance's NHP specification, concealing ports, IPs, and domains behind a default-deny cryptographic gate for authorized defenders.
| Tool | OpenNHP/opennhp — reference Go implementation of the CSA Network-infrastructure Hiding Protocol for Zero Trust infrastructure concealment |
| Category | Zero Trust network access / infrastructure hiding toolkit |
| Primary Use | Deploying default-deny access control where NHP-Agent knocks unlock protected services for authenticated, authorized users in enterprise environments |
| Safe Use | Defensive deployment on infrastructure you own or administer during authorized security architecture work, lab evaluation, and Zero Trust rollouts |
| Telemetry Note | From the defender's chair, OpenNHP makes protected services port-scan-invisible: unauthenticated probes get no response, while authenticated NHP_KNK knocks and subsequent NHP-AC firewall openings generate audit events on the server and access controller |
OpenNHP/opennhp is a lightweight, cryptography-powered open-source toolkit that implements Zero Trust security for infrastructure, applications, and data. It is the reference implementation of the Cloud Security Alliance's Network-infrastructure Hiding Protocol (NHP) specification, and with nearly 14,000 stars and an Apache-2.0 license, it has quickly become the most visible project in the infrastructure-hiding niche. Written entirely in memory-safe Go, it positions itself against a threat model the README describes bluntly: LLM-assisted scanners fingerprinting and exploiting every reachable service at machine speed. The project's thesis is compressed into one line — visibility equals vulnerability — and the entire architecture is built to remove that visibility.
The core inversion OpenNHP performs is moving authentication before network access rather than after it. Traditional defenses let a TCP handshake complete and then challenge the caller, which means exposed ports, IPs, and hostnames are a permanent attack surface available for reconnaissance. OpenNHP puts every port, address, and hostname behind a default-deny gate, and access is granted only after a cryptographically signed knock is authenticated and authorized out-of-band. An attacker cannot exploit what they cannot discover, and with NHP there is nothing to discover until trust is established.
The README situates NHP as a third-generation protocol in a lineage the author clearly enjoys mapping. Generation one was classic port knocking, which was plaintext and replay-prone. Generation two was Single Packet Authorization (SPA), which suffered shared secrets, one-directional messaging, and typically hid ports only, usually implemented in C or C++. NHP claims the third generation: modern cryptography, bi-directional messaging with status feedback, concealment of domain plus IP plus ports, stateless and horizontally scalable design, and the memory safety of Go. That comparison table is honest about prior art while making a credible technical case for what changed.
Architecturally, the project follows the NIST Zero Trust Architecture model and splits into three core daemons plus two addons. NHP-Agent is the client that sends encrypted knock requests; NHP-Server authenticates and authorizes those requests and is deliberately decoupled from the protected host; NHP-AC is the access controller that manipulates firewall rules on the target machine. The decoupling of the authorizing server from the protected resource is a meaningful design choice, because compromising the protected host does not immediately yield the policy plane. On the addon side, NHP-Relay provides an HTTP-to-UDP bridge so browser-based agents can send knocks over HTTPS, and NHP-KGC acts as a Key Generation Center for Identity-Based Cryptography.
The protocol flow is documented as a five-step exchange. The agent sends an encrypted knock (NHP_KNK) to the server; the server validates it and forwards an operation request (NHP_AOP) to the access controller; the AC opens the firewall and replies with NHP_ART; the server returns an acknowledgment (NHP_ACK) carrying access information to the agent; only then does the agent reach the protected resource through the AC. Each message type is a distinct protocol primitive, and the bi-directionality is what distinguishes NHP from one-way SPA implementations — the agent learns whether authorization succeeded and what it may touch.
The cryptography layer is where the project shows its engineering discipline. Two interchangeable cipher suites ship in the codebase: CIPHER_SCHEME_CURVE, combining Curve25519, AES-256-GCM, and BLAKE2s, and CIPHER_SCHEME_GMSM, the Chinese national suite combining SM2, SM4-GCM, and SM3. Both are driven by the Noise Protocol Framework, the same well-audited pattern underpinning WireGuard-style handshakes, rather than a bespoke handshake design. An Identity-Based Cryptography mode is available through the KGC, which lets identities derive directly from attributes instead of pre-distributed certificates — useful for large fleets where key distribution is the operational bottleneck.
Repository layout reflects the modular design. The nhp/ module holds the core protocol library, with core/ covering packet handling, cryptography, the Noise Protocol integration, and device management; common/ for shared types; plugins/ for handler interfaces; log/ for observability; and etcd/ for distributed configuration, a nod to horizontally scaled deployments. The endpoints/ module depends on nhp and contains the daemon implementations: agent/, server/, ac/, plus db/ for the NHP-DB Data Broker serving the Data-content Hiding Protocol, kgc/, and relay/. Separating library from daemons is good hygiene — it means third parties can embed the protocol without running the full stack.
Beyond network hiding, the README describes a second protocol, DHP (Data-content Hiding Protocol), which addresses data security and privacy through encryption and confidential computing, summarized as making data usable but not visible. The NHP-DB broker in the endpoints tree is the implementation vehicle. The framing suggests an enclave-style model where computation happens over encrypted content, though the README defers details to the project documentation rather than elaborating in-repo, so treat DHP as the younger sibling of the two protocols.
Building is straightforward and standard for a Go project: make builds all components, with per-daemon targets like make agentd, make serverd, make acd, make db, make relayd, and make kgc. Prerequisites are Go 1.26+, make, and Docker with Docker Compose for the full-stack demo. Tests run via go test ./... in both the nhp/ and endpoints/ trees, and the CI badge plus a codecov badge indicate the project takes build and coverage hygiene seriously. The Docker path is the sensible entry point for evaluation: cd docker && docker-compose up --build stands up the whole workflow so you can observe the knock-to-access exchange in an isolated lab before touching production topology.
Importantly, NHP is designed to slot alongside existing identity and policy infrastructure rather than replace it. The README explicitly notes it works alongside IAM, DNS, FIDO, and Zero Trust policy engines — it extends the stack instead of forking it. For an operator, that means OpenNHP is best evaluated as a concealment layer in front of services you already govern with policy, not as a wholesale identity replacement. The project's etcd support and stateless design also matter here, since horizontally scaling the knock-processing plane is usually where SPA-style systems fall over in real deployments.
Operational maturity signals are decent: a SECURITY.md responsible-disclosure process, a CONTRIBUTING.md requiring GPG- or SSH-signed commits (git commit -S), multi-language READMEs in English, Chinese, German, Japanese, French, Spanish, and Indonesian, a Discord community, and sponsors including Tencent Cloud. The documentation lives at docs.opennhp.org with a dedicated Quick Start tutorial for simulating the full authentication workflow in Docker. For defenders, the observable footprint is distinctive: unauthenticated scans see nothing because nothing responds, while legitimate knocks produce a clean audit trail across NHP-Server and NHP-AC logs — a rare case where the telemetry story improves as the attack surface shrinks.
OpenNHP/opennhp.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.