Skip to content

Add secure single-port HTTP proxy transport - #1594

Draft
BenCodez wants to merge 1 commit into
masterfrom
codex/http-transport
Draft

Add secure single-port HTTP proxy transport#1594
BenCodez wants to merge 1 commit into
masterfrom
codex/http-transport

Conversation

@BenCodez

Copy link
Copy Markdown
Owner

Summary

  • add BungeeMethod: HTTP as a bidirectional, outbound-backend transport using one proxy HTTPS port
  • automate a private CA, proxy TLS identity, node-bound one-time enrollment codes, per-backend client certificates, persistence, revocation, and certificate pinning
  • integrate the transport across Bungee/Velocity config, backend lifecycle, proxy routing, Control validation, vote handling, commands, and cleanup
  • add bounded long polling, persistent HTTP/1.1 connections, acknowledgements/deduplication, byte-budgeted batching, bounded queues/executors, admission/rate limits, and strict protocol parsing
  • document the quick setup and Internet-facing threat model in docs/http-transport.md

Easy setup

  1. Select HTTP on the proxy and set HTTP.PublicEndpoint.
  2. Open only the configured proxy port.
  3. Run /votingpluginbungee httpcode <server>.
  4. Paste the code into that backend's HTTP.ConnectionCode and restart it.
  5. Remove the temporary code after enrollment. The generated client identity is reused automatically.

Compromised or replaced nodes can be revoked with /votingpluginbungee httprevoke <server>.

Security

  • TLS 1.3 only, exact proxy/CA pins, hostname verification, certificate validity/signature/CA checks
  • client certificates bound to canonical backend identities and revalidated at the application boundary
  • 256-bit, 15-minute, single-use enrollment capabilities bound to one requested backend
  • owner-only atomic key, profile, binding, and revocation persistence where supported
  • fixed, bounded request bodies with request/response deadlines; no chunked uploads or redirects
  • exact endpoints/methods/content types, replay sequences, deduplication, and authenticated identity normalization
  • bounded connections, concurrent polls, worker queues, message queues, batches, packet bytes, and per-node request rates

The application cannot by itself prevent volumetric link/TCP floods; the documentation recommends host/provider firewall protection for Internet exposure and requires direct TLS pass-through.

Performance

  • all network and certificate work is off the game thread
  • reused HTTP/1.1 TLS connections
  • two-second bounded long polls for predictable backend-origin latency
  • message/ACK batching that splits on the fully serialized 256 KiB packet budget

Verification

  • mvn test: 509 tests passing
  • mvn package: passing, including the shaded artifact
  • git diff --check: passing
  • independent security review: SHIP after remediation of slow-body exhaustion, unbound enrollment, session dedup, oversized queue/packet, identity mismatch, canonical routing, and TLS validation findings

Delivery semantics

Transport queues are bounded and in-memory with in-process at-least-once delivery. Existing VotingPlugin vote caching remains responsible for application-level restart durability.

KeyManagerFactory keyManagers = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagers.init(store, password);
SSLContext context = SSLContext.getInstance("TLS");
context.init(keyManagers.getKeyManagers(), new TrustManager[] { new EnrollmentAwareTrustManager(caCertificate) }, null);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants