Hackathon: passive origin/topology recon of the demo (your port-hiding held; CT/DNS leak flag) — from a very new IETF newcomer

Hi OpenNHP team

First, a confession, because it feels only fair: until this morning I had never heard of the IETF. We're a small, bootstrapped threat-intelligence shop in Minnesota. We stumbled into all of this because we found one of our write-ups cited in the IETF 126 hackathon wiki, went "…the what task force?", and then decided the neighborly thing to do was actually show up and help rather than just be flattered. So please read everything below in that spirit — a newcomer poking at your project because you kindly invited people to, not an authority pronouncing anything.

You explicitly invited participants to try to enumerate and bypass the hiding, so we pointed our recon toolkit at the public demo (opennhp.org). Passive public evidence only — Certificate Transparency, DNS, and Shodan InternetDB via our public enrichment API. No port scan, no packet sent to any protected service, and no authentication attempted or bypassed. We want to be very clear on that last point.

First, the part that made us tip our hats: your port-hiding held. The Access-Control tier (ac, ac2, acdemo, nhp) is discoverable by IP, yet Shodan sees no open ports on any of them — IP known, ports dark. That's the property you're selling, and it worked. A single passive HTTPS header read against the exposed hosts also returned nothing, which is consistent with an auth-before-connect gate doing its job. Nice.

The one thing we'd gently flag for the threat model: everything the packet layer doesn't govern still leaks. Certificate Transparency + DNS handed us your entire component topology — agent, relay, registration, both AC servers, auth-plugin, demologin — and their origin IPs behind the Cloudflare front. One host (nhp.opennhp.org) wasn't even in CT; we found it by ordinary subdomain expansion. So an attacker maps the whole deployment before NHP is ever in the path. Two support-tier hosts also expose :443 directly (one carries a Shodan eol-product tag — unverified by us, so please don't take our word for it). None of this defeats your hiding; it's a note that a hiding protocol's threat model probably wants to treat CT/DNS enumeration of protected endpoints as in-scope, and that the non-NHP support hosts are the softer edge.

Supply chain: we also ran your js-agent npm dependencies through our checker — clean, and honestly better hygiene than most projects we audit (@noble/* audited crypto, sm-crypto-v2, cbor-x; nothing malicious, nothing in CISA KEV, no exploitable chain we could find).

Threat-corpus cross-check: clean — none of your infrastructure appears in our threat data. Legitimate demo hosts, said plainly.

Full write-up, an attributed architecture diagram (Mermaid), and the raw, reproducible tool output are here: https://github.com/pduggusa/dugganusa-ietf/blob/main/network-infrastructure-hiding-nhp/FINDINGS-opennhp-demo.md

You can reproduce the core of it in one line, no key needed: node recon-toolkit/origin-recon.js opennhp.org. The whole automated sweep runs in ~2.8 seconds.

Thank you for building this in the open and for inviting people to kick the tires — it's a genuinely cool project, and we're glad the first thing we did after learning what the IETF is was try to be useful to one of its projects. Happy to help however's useful, and apologies again for being a day-one newcomer to all of this.

— Patrick Duggan, DugganUSA LLC