Sunlionet

Security Policy

SunLionet assumes adversarial transport, hostile local networks, and untrusted distribution media. The system is designed to fail closed: unverified configuration bytes are never applied, revoked signers are rejected offline, and Android routing keeps the VPN interface established during proxy-core failure or network churn.

Supported Versions

Version Supported
0.3.x-rc1 Yes
< 0.3.0 No

Responsible Disclosure

Do not open public issues for vulnerabilities.

Report security issues to security@sunlionet.org with GPG-encrypted details when possible. Include:

The Security Response Team acknowledges reports within 24 hours. P0/P1 fixes are targeted within 24-72 hours after confirmation. Public advisories are published only after a fixed release or mitigation path exists. See Vulnerability Response Lifecycle.

Trust Assumptions

Cryptographic Constraints

Bundle Verification

Offline Revocation

Trust updates use:

Rollback, stale version, invalid previous hash, and insufficient threshold signatures are security failures.

Accepted forms:

The base64url payload is capped at 300 characters. The signed message is:

"SUNLIONET-ONBOARDING-V1\x00" || unsigned-envelope

The envelope is rejected unless the embedded signer public key is already trusted. Activation windows may not exceed 24 hours. Host, SNI, tag, and credential fields are strictly length and character filtered before profile storage.

Erasure Chunks

Chunk magic is SNCE, version 1, text wrapper SNBEC/1. Each chunk has a local SHA-256 checksum and the full payload SHA-256. Reassembly only repairs transport bytes; trust is granted only after the reconstructed bundle passes Ed25519 verification.

Telemetry

Telemetry is opt-in only and dormant by default. Payloads contain enum counters only. No profile IDs, source IPs, SSIDs, IMEI, timezone, device IDs, route names, free text logs, or precise timestamps are accepted. Batches are time-blurred 24-72 hours and encrypted per transmission with fresh X25519 ephemeral keys, HKDF-SHA256, and ChaCha20-Poly1305.

Data-Leak Containment Invariants

Secure Coding Rules

Extension Review Checklist

For a new transport or proxy backend:

  1. It implements proxycore.ProxyCore.
  2. Validate is side-effect free and context-cancelable.
  3. HotReload assumes the kill switch is engaged and emits no plaintext.
  4. Stop is idempotent.
  5. Health checks are passive or obfuscated.
  6. It has tests for timeout, degraded health, restart, and all-candidate failure.
  7. It does not import identity stores unless it is explicitly an identity module.
  8. It passes go test ./... and go test ./tests/chaos.
  9. Race-sensitive changes pass Linux go test -race ./tests/chaos.

Audit Scope Hints

High-value audit targets:

Incident Handling

If a signing key is compromised:

  1. Generate a TrustUpdateBlock with revoke_signer.
  2. Sign it with the configured root threshold.
  3. Distribute it over all offline media.
  4. Verify clients reject bundles from the revoked key.
  5. Publish advisory after mitigation is available.

If a VPN leak is suspected:

  1. Stop rollout.
  2. Reproduce with chaos and Android network-switch tests.
  3. Verify TUN route ownership, DNS servers, and HOLDING state.
  4. Patch before enabling new transport features.