[fionera]

Overview

Implements a broad bot-blocker feature set on top of Berghain (modelled on the "Gandalf" spec), while keeping the core design intact: Berghain stays stateless (all runtime state lives in HAProxy stick-tables/maps), the Go hot path stays zero-allocation, and HAProxy owns policy while Berghain remains a pure SPOE function. Also closes four open issues.

Opened as a draft — it's a large surface and likely wants to land in smaller pieces / with maintainer input on scope. Commits are grouped so they can be cherry-picked or split.

What's included

Challenge engine (Go + web)

• Per-level configurable PoW difficulty (leading-zero bits, default 16, range 1–255), advertised via a fixed-width d field; the server enforces its own level's difficulty.
• New pow-worker challenge type — same PoW, must be solved in a Web Worker (inlined into the single-file bundle).
• Browser capability detection with actionable advisories, a session id (ena@<uuid>), and a ban-countdown screen.

HAProxy policy (stateless)

• Three rate limiters (global, per-IP burst, challenge-endpoint anti-bruteforce) within the 3-stick-counter budget, a flat temporary ban + countdown page, an AI/scraper tarpit, and keyed IP log-hashing (Go HashSource + HAProxy).
• Reputation/ASN/VPN/Tor/Cloudflare maps with an onion/I2P bypass, fed by a new cmd/feedupdater tool.
• Optional CrowdSec integration scaffold for community reputation + escalating bans.

Docs & ops

• A self-contained, JS-free help page under docs/ + a GitHub Pages workflow.
• README configuration + operations documentation.

Closes

• Closes Add browser e2e test #9 — browser e2e test (headless Chrome drives the real client through the full stack; wired into CI).
• Closes Haproxy sample config for usaergant based filtering #19 — User-Agent / endpoint filtering example config (haproxy-ua-filtering.cfg + maps).
• Closes Templating for the challenge page #26 — challenge-page hooks system (VITE_HOOKS) so branding/behaviour can live in a separate repo without forking web/.
• Closes Cross-Domain validation for non-standard ports #46 — cross-domain validation now strips the port from the Host header (identity, trusted-domain match, cookie Domain, and the HAProxy onion bypass).

Verification

• go build/test/vet + staticcheck clean; the Go hot path stays 0 allocs/op.
• npm run lint + npm run build (both default and native-crypto modes, single-file output).
• haproxy -c valid for both example configs.
• Browser e2e passes against a live stack (challenge solved end-to-end).
• feedupdater unit-tested and confirmed against live feeds.

Notes

• The inlined Web Worker grows the challenge page past HAProxy's default 16k buffer, so tune.bufsize is raised to 32k.
• A gpt-5.5 code review was run over the branch; its three findings (a zero-difficulty fail-open, the onion-port bypass gap, and a CI e2e that could pass without exercising the stack) are fixed in this PR.
• CrowdSec is an opt-in scaffold, not wired into the default stack.

[fionera]

Live IP reputation via the HAProxy peers protocol

Replaced the map-file approach for individual-IP reputation with the HAProxy peers protocol (as implemented in haproxy-go), so entries are pushed into HAProxy's stick-tables live, with no reload.

What changed

• New internal/peerserver implements the sending side of the peers protocol (haproxy-go only had the receive side). It handles the handshake, table definitions, entry updates, sync and heartbeats. (Entry data is marshalled by hand — EntryUpdate.Marshal mis-encodes the data section upstream, calling Unmarshal.)
• cmd/feedupdater now runs as a peer: Tor exit nodes → gpt0=3 (challenge), banlists → gpt0=1 (block), served live into st_reputation_v4/st_reputation_v6. haproxy.cfg gains a peers berghain section and consults the gpt0 tag.
• CIDR/range feeds (Cloudflare, ASN, VPN) stay as map/ACL files — stick-tables key on exact IPs and can't do longest-prefix matching. feedupdater still refreshes those atomically.
• ban.map / reputation.map / tor_exit.map deleted; docker-compose runs feedupdater as the peer (haproxy -L haproxy_local).

Validated against real HAProxy (--network host):

• feedupdater pushed 1378 entries; show table st_reputation_v4 → used:1378 (Tor IPs gpt0=3, banned 127.0.0.1 gpt0=1).
• A request from the banned IP was silent-dropped (http=000), with no reload.
• Full docker compose stack + browser e2e still green.

[fionera]

The omnibus branch has been rebased onto the current origin/master and this PR is superseded by focused draft PRs:

Core challenge behavior

• fix(spop): normalize Host authorities #60 Host authority normalization
• feat: configure proof-of-work difficulty #62 configurable, signature-bound POW difficulty
• feat(web): add Web Worker proof of work #69 Web Worker POW (stacked on feat: configure proof-of-work difficulty #62)

Frontend and supportability

• feat(web): add build-time challenge hooks #61 build-time challenge hooks
• feat: add challenge support IDs #63 per-page support IDs
• feat: pseudonymize source addresses in logs #70 pseudonymous source logging (stacked on feat: add challenge support IDs #63)
• feat(web): report missing challenge capabilities #64 capability diagnostics

HAProxy policy

• feat(haproxy): add request admission limits #65 request admission limits
• feat(haproxy): ban repeated challenge attempts #71 repeated-attempt bans (stacked on feat(haproxy): add request admission limits #65)
• feat(haproxy): add optional User-Agent policy #67 optional User-Agent policy

Live reputation

• feat(haproxy): add atomic Runtime API map updates #66 atomic Runtime API map updates
• feat: add validated reputation feed updater #72 validated feed updater (stacked on feat(haproxy): add atomic Runtime API map updates #66)
• feat(haproxy): apply live reputation policy #73 live reputation policy and container wiring (stacked on feat: add validated reputation feed updater #72)

Verification

• test(e2e): exercise the browser challenge flow #68 deterministic browser E2E and CI repair

The custom peers-protocol implementation was replaced by HAProxy’s supported atomic Runtime API. The nonfunctional CrowdSec starting-point scaffold was intentionally not carried into these PRs; a real CrowdSec integration should be implemented and tested as a follow-up.