Skip to content

Hub Host Security Guidance

This page is customer-facing security guidance for organizations deploying a QIE Hub. It exists because the Hub concentrates authority that requires explicit acknowledgement and host-hardening beyond a normal QIE engine deployment.

Treat this as the minimum baseline. Defense-in-depth against sophisticated adversaries requires controls beyond what is documented here.

The inherent risk

A compromised Hub can send arbitrary HTTP to every connected site's local Jetty, as if it originated from localhost on that site's host. That network position is the purpose of the design. It is what allows centralized management without inbound firewall holes at every site, and no technical control inside this system removes it. What that does and does not mean is worth stating precisely.

The Hub terminates TLS, so it handles cleartext. Browser→Hub (HTTPS) and Hub→site (the mTLS tunnel) are both encrypted on the wire. But the Hub is a legitimate endpoint of both connections: it decrypts each request to route it, enforce the per-site PROXY ACL, and rewrite headers, then re-encrypts it onto the tunnel (and the reverse for responses). So every proxied request and response passes through the Hub process in cleartext, decrypted on the way in, re-encrypted on the way out. This is the same exposure any TLS-terminating reverse proxy or load balancer carries (nginx, an ALB doing TLS termination, and the like): ciphertext on both sides of it, cleartext within it. An attacker who controls the Hub JVM therefore sees, in cleartext at the Hub, everything flowing through an active proxied session:

  • PHI carried by the operator's admin actions;
  • site login credentials. Every login an operator submits to a site is cleartext in the Hub process before it is re-encrypted and forwarded, so it can be captured and replayed;
  • the site's session cookie, likewise cleartext in the Hub process on every proxied request, so an active session can be hijacked or have requests injected into it.

To be clear, none of this is cleartext on a network link. Both hops are encrypted between the nodes. It is cleartext at the Hub because the Hub is the endpoint that must decrypt to do its proxy job, exactly as any TLS-terminating proxy must.

The site still authenticates every proxied request. The proxy grants no standing access. The tunnel is transparent: the site's own login (local users / LDAP / OIDC) is unchanged, the Hub injects no credentials, and an unauthenticated proxied request receives the site's normal login screen. A Hub compromise therefore does not, by itself, hand an attacker the admin UI, PHI, or channel configuration of a site. What it yields is the network position to reach the site, plus the man-in-the-middle ability to capture or ride an operator's session as it is used. A site nobody is actively managing through the Hub is not directly exposed to data theft this way (the control-plane exception below aside). The practical worst case is still real. As operators work through a compromised Hub, credential harvesting and session hijack extend to every site they touch, but the mechanism is interception, not a master key.

Control plane: the site does trust the tunnel for its own lifecycle. Independently of proxied HTTP, a site acts on Hub-issued tunnel control commands (client-cert cycling and revocation, CA-trust changes, graceful shutdown) without a site login, since that is how the Hub manages fleet PKI and connections. A compromised Hub can abuse this to disrupt: shut sites down, force certificate churn, or revoke/lock out a site's client cert. That is denial-of-service and PKI manipulation, not data access.

The other concentrations of authority are unchanged:

  • The Hub internal CA's private key can sign client certs for any site identifier. Loss of that key allows an attacker with network access to the tunnel listener to impersonate any registered site.
  • A Hub operator has PROXY reach to every site they are granted and can drive the interception described above; where the same person also holds site admin credentials, that role is effectively a hospital-network-wide admin. Grant it accordingly.

You must accept this risk to deploy the architecture. The point of this page is to make sure you accept it deliberately, for exactly what it is, neither more nor less, and harden accordingly.

Treat the Hub as a tier-1 administrative host

In your operational model, the Hub belongs in the same trust tier as:

  • Active Directory domain controllers / equivalent identity systems
  • Privileged access management (PAM) bastions
  • Backup orchestration hosts

It does not belong in the same tier as application servers or general workload hosts. Specifically:

  • Host it on dedicated infrastructure, not co-tenanted with general application workloads.
  • Restrict administrative access (SSH, Remote Desktop, vSphere hub, etc.) to the same operator population that already has tier-1 admin access elsewhere in your environment. Do not extend it to QIE channel operators, hospital site admins, or general developers.
  • Patching cadence: same as your tier-1 hosts. The Hub host's OS, Java runtime, Jetty, and QIE WAR must be kept current. Public CVEs in any of these have a credible path to Hub compromise.

Network segmentation

The Hub exposes two ports with different threat surfaces and should be firewalled accordingly:

Port Reachable from Why
Dashboard (e.g. 443/8080) Operator workstations / VPN Authenticated human access only
Tunnel listener (e.g. 8443) The IP ranges of registered QIE sites mTLS-only; opens nothing to unauthenticated traffic

Specifically:

  • The tunnel listener port should not be exposed to the public internet unless you have no other option. If your QIE sites reach the Hub over an MPLS / SD-WAN / customer-VPN underlay, restrict the tunnel port to those source ranges at the network edge. Defense-in-depth: mTLS would still block an unauthenticated attacker on the listener port, but every layer counts.
  • The dashboard port should not be exposed to the public internet in most deployments. Place it behind a VPN or zero-trust proxy. The dashboard accepts password-style credentials (subject to whatever authentication backend your Hub is configured for); exposing it publicly invites credential stuffing and brute force.
  • Egress filtering: the Hub JVM should have no outbound network reachability beyond what it needs. The only public-Internet destination QIE requires is the daily license check-in to https://www.qvera.com. Everything else the Hub talks to is infrastructure you control: the database (required), and, where configured, your identity provider (OIDC / LDAP) and an SMTP relay for alerts, plus optional log shipping. This contains the blast radius if the JVM is compromised.

Operator authentication

The Hub reuses QIE's existing authentication (local users, LDAP, OIDC). For Hub deployments:

  • Prefer SSO + MFA via your enterprise identity provider (OIDC). Local username/password authentication on a tier-1 host is a liability. Every operator's password becomes a target.
  • Enforce account hygiene on whatever IdP you use: MFA enrollment, password rotation, account-disable on offboarding. The Hub inherits whatever your IdP does; it does not add its own MFA.
  • Limit operator population. A user who can log in to the Hub dashboard can see every site they have an ACL for. Audit this list quarterly.
  • Use per-site ACLs to scope individual operator access to the sites they actually manage. Hub administrators bypass ACL checks, so minimize that role.

Audit log

The audit log is your primary forensic resource if anything goes wrong. Treat it as evidence:

  • Ship hub-audit.log off-host continuously. See ACL and Audit Log. An attacker who reaches the Hub JVM can also reach files on disk; an off-host copy in a SIEM you control is the integrity anchor.
  • Watch for TUNNEL_TAKEOVER_DETECTED storms. Rapid repeated takeovers (multiple events for the same site within minutes) are the primary detection signal for cert exfiltration. See ACL and Audit Log.

  • Alert on BUNDLE_REUSE_REJECTED. A bundle being submitted a second time means either the legitimate site's registration attempt has been preempted by an attacker who intercepted the bundle, or the operator accidentally tried to reuse a consumed bundle. Either case warrants attention.

  • Alert on BUNDLE_REVOKED_REJECTED. Somebody attempted to redeem a bundle an operator had deliberately cancelled. This is the stronger signal of the two: the bundle was recalled for a reason, and something still holding it is trying to enroll. Treat it as an attempted enrollment by an unintended holder until you have established otherwise.

  • Alert on repeated HUB_LOGIN_FAILURE from the same source IP. The Hub does not by itself lock accounts after N failures; rely on the upstream IdP or a SIEM rule.
  • Retain audit logs long enough to satisfy your regulatory obligations (HIPAA, state privacy law, customer contractual commitments). The on-host file rolls at 50 MB × 20 = 1 GB and cannot serve as long-term archival.

Key custody

The Hub-internal CA's private key is the single most sensitive artifact on the Hub host.

  • The key is stored in the global zone's SSL Certs / Keys table as part of the QIE database. Whatever protects the database protects the key. Encrypted-at-rest database storage, restricted DB user permissions, and DB backup encryption are all on the critical path.
  • HSM / PKCS#11 storage is a planned post-v1 enhancement. When it ships, it will let you move the CA key into a hardware security module so even DB compromise does not leak the key. For now, database protection is what stands between an attacker with DB access and full impersonation of any site.
  • Know the CA rotation procedure before you need one. On a confirmed CA-key compromise, rotate the internal CA with the Stage New CA → Re-issue All Client Certs → Activate New CA → Retire Old CA ceremony. It runs with a dual-CA overlap. The Hub trusts both CAs and sites migrate to new-CA client certs while still connected. so it does not require a flag-day re-enrollment of the fleet (only a site offline for the entire window needs manual re-enrollment). Retire is gated until every connected site has migrated. See Rotating the internal CA.

Path-based routing (a security trade-off)

Subdomain-per-site routing is strongly recommended because it gives each site its own browser origin. The optional path-based mode (-Dqie.hubProxyAllowPathBased=true) instead serves every site under the Hub's single origin, which removes that isolation:

  • Every site shares the Hub host's browser origin.
  • Cookies and JavaScript can read across sites the same operator has open in different tabs.
  • A compromised site can run arbitrary JavaScript against another site's open admin UI.

Path-based is provided for deployments that cannot provision per-site wildcard DNS and a wildcard TLS certificate. If you enable it, you are accepting these risks in exchange for that operational simplicity. Treat it as a deliberate, documented decision, not a default, and prefer wildcard DNS + a wildcard cert with subdomain routing wherever you can.

Confirm whether path-based is enabled on each Hub instance during your deployment review, so the setting is intentional rather than accidental:

ps aux | grep qie.hubProxyAllowPathBased

These are not required to ship a Hub but materially improve resilience to specific threats:

  • Disk encryption on the Hub host. Standard for tier-1 hosts.
  • Process-level egress filtering (cgroups, systemd NetworkPolicy, host firewall with per-binary rules). The Hub JVM should not be able to dial out to arbitrary internet hosts. The only outbound Internet call QIE must make is the daily license check-in to https://www.qvera.com, a combined licensing / update-notification / usage-reporting heartbeat (miss it for several consecutive days and QIE warns, then stops channels, then locks down). Allow that one destination and deny the rest of the public Internet. The optional auto-update build download also targets qvera.com; block it and apply updates manually if you prefer. It is not required for normal operation.
  • Time-of-use audit log monitoring. A rule that pages on-call when sensitive events fire (cert revocation, ACL grant, bundle generation) gives you a chance to catch unauthorized operator actions in close to real time.
  • Configuration drift detection on the hub_listener_config row and the SSL Certs / Keys tables. Unexpected changes to the server cert, internal CA, or external URLs deserve investigation.
  • Periodic re-validation of the deployment. Quarterly: review operator population, ACL grants, revocation list. Annually: full security review against your threat model.

What is NOT in scope for this guidance

  • Defending against insiders with legitimate Hub operator access who abuse their authority. The audit log records what they did; deterrence and personnel controls are your problem.
  • Defending against compromise of the operator's workstation. If an operator's browser is owned, every Hub session they have open is also owned. Standard endpoint hygiene applies.
  • Defending against compromise of the remote QIE site host. A compromised hospital-site QIE can lie to the Hub about its status, exfiltrate PHI through legitimate-looking admin actions the operator is authorized to perform, etc. Site host hygiene is out of Hub scope.

Reporting a vulnerability

Security issues in the QIE Hub (or any QIE component) should be reported privately to Qvera via the established responsible disclosure channel. See your support contract for the dedicated security contact. Please do not file public issues for unpatched vulnerabilities.