StartOS start-tunnel 1.2.0

Original release notes

What's Changed

Changed

**Web UI and CLI authentication moved from session cookies to per-device

signing keys.** Logging in now enrolls an Ed25519 public key with the server, and every API request is signed with the matching key instead of carrying a session cookie. Enrolled keys appear in the key list with their user agent and last-active time, and auth session commands now manage enrolled keys. All existing sessions are signed out on upgrade - sign in again on each device. Request signatures are bound to a server identity; IPv6 addresses from the TLS certificate's SANs count in their URL form ([...]), matching how clients actually address the server. HTTP cookies are gone from the API entirely: the server no longer sets or reads any cookie, and the start-tunnel CLI run on the server itself presents the local authcookie as an Authorization: Bearer header instead of a Cookie (its --cookie-path flag is removed).

The device key is a non-extractable WebCrypto key held in IndexedDB: page scripts can sign with it while the page is open, but can never read the key material out. Logging in requires a browser with Ed25519 WebCrypto support - any evergreen browser (Safari 17, Firefox 130, Chrome/Edge 137, or newer).

Added

DNS over the tunnel's IPv6. Each subnet's DNS proxy now also listens on

the server's IPv6 address out of the subnet's delegated prefix, and RFC 2136 injection is authorized for a device's tunnel IPv6 on the same terms as its IPv4 - so a StartOS server can publish (and refresh) its automatic records, including the AAAA record for its .local name, over either family.

Fixed

Deleting a fallback forward now actually deletes it. A PCP delete

(lifetime 0) or UPnP DeletePortMapping for a hostname-less forward that had become an SNI port's fallback reported success but silently left the fallback in place, so the port stayed open to the fallback device until its lease lapsed (up to an hour). Both delete paths now clear the fallback immediately; named SNI routes on the port are unaffected.

Security

The web UI ships a strict Content-Security-Policy. Every response from

the UI origin now carries a CSP restricting scripts and network connections to the server's own origin (no framing, no plugin content), plus X-Content-Type-Options: nosniff. A script injection that slips into the page can no longer pull in outside code or exfiltrate to a foreign host.

Documentation

FAQ: .local on Android. New entry explaining why .local addresses stop

resolving on Android once a WireGuard config carries the DNS = line (Android excludes VPN connections from mDNS resolution, so the lookup goes to the tunnel's resolver instead - breaking .local even on the home LAN), and how a connected StartOS server now fixes this automatically by injecting a record for its .local name over the tunnel (with the manual DNS-record workaround kept for when DNS injection is disabled). The DNS Records page note now mentions the .local name is injected too.

start-tunnel packages Checksums

SHA-256

fe7a2b1b8366ce0a660d9c71b840627522ecbb6746e0039d668500312b45b682  start-tunnel-1.2.0-e7ed569_aarch64.deb
a2679ac70135039d2e991ca8894e9dd52b31149b1d48d595c0f63b8a0762e951  start-tunnel-1.2.0-e7ed569_riscv64.deb
8a9c7abcb55c3bcb65f3124a33ddf33148b3bdfe0ae32e4b881af7dccabe1a5b  start-tunnel-1.2.0-e7ed569_x86_64.deb

BLAKE-3

b2bc6f08f1f78b9c95777bc16d106caa4c4fff91bfdb7f2864e635799e8ccfdd  start-tunnel-1.2.0-e7ed569_aarch64.deb
34fc367493f673f370ab0718d1d0506b79688a7d5c015d0e68f3838cd3afda1d  start-tunnel-1.2.0-e7ed569_riscv64.deb
c2b228b7fbb792af4d234b0ce322803e05c4fab159b611435f6209811723b231  start-tunnel-1.2.0-e7ed569_x86_64.deb