Skip to main content

HTTPS Bootstrap For Stronger Server Identity

This describes a proposed design for adding stronger server identity to secure datagram connections, without reintroducing manual setup friction. It is not yet implemented. The active runtime currently uses:

  • ephemeral in-memory server keys per process lifetime
  • no pinned public-key validation

Problem​

Stronger server identity is desirable, but it creates an operational challenge:

  • game servers may run in containers
  • servers may move between VPSes
  • multiple instances may exist behind one service
  • manually copying the public key into clients does not scale

The missing piece is not the secure-session handshake itself. The missing piece is how the client gets the correct expected server key before it opens the datagram session.

Proposed Solution​

Introduce a trusted HTTPS control plane.

High-level flow:

Client -> HTTPS control plane
       <- server endpoint + expected server public key

Client -> game server
       -> secure-session handshake
       -> validate server public key against the bootstrapped expected key

This keeps the datagram secure-session model mostly unchanged while adding a stronger trust anchor than the current no-pinning runtime.

Why HTTPS Bootstrap Helps​

It solves the main problems that TOFU does not:

  • strong server identity on the first connection
  • easier multi-server and autoscaling support
  • easier deployment across docker/Kubernetes/VPS fleets
  • central key rotation and rollout control

Suggested Bootstrap Payload​

The HTTPS control plane could return:

{
  "service": "entangle-prod",
  "region": "eu-west-1",
  "host": "play.example.com",
  "port": 5559,
  "provider": "ENet",
  "publicKeyRaw": "BASE64_RAW_PUBLIC_KEY",
  "expiresUtc": "2026-06-01T00:00:00Z"
}

Possible future additions:

  • signed manifest
  • key version / rotation window
  • region failover list
  • ticket/token for matchmaking or room join

Operational Model​

Recommended production shape:

  • one persistent keypair per logical service/cluster
  • all datagram servers behind that service share the same keypair
  • the public key is distributed by HTTPS control plane
  • the private key is provisioned securely to game servers

This avoids making identity depend on a single machine or container lifetime.

Optional Hardening​

Later phases could add:

  • signed key manifests
  • offline root verification keys
  • expiry and rotation metadata
  • certificate pinning on the HTTPS bootstrap itself

Relationship To Current Runtime​

Current runtime:

  • no pinned key in config
  • one ephemeral keypair per server process lifetime

Future HTTPS bootstrap:

  • fetch expected key material from a trusted HTTPS backend
  • validate the datagram server against that key during handshake

That means the secure-session protocol can stay mostly the same while the trust model becomes much stronger.