Skip to content

Dropbox & Proxy Services

The Dropbox subsystem provides a self-hosted, stealthy TLS proxy that sits in front of a filebrowser instance, handling authentication, TLS termination, and HTTP-to-HTTPS redirection. It operates as a single-port listener that inspects incoming connections to distinguish between TLS handshakes and plain HTTP, routing them to appropriate handlers. The service is designed to be stateless regarding client connections but relies on local file-based state for secrets and credentials, coordinated with the broader autosre configuration system.

Configuration is managed through the DropboxConfig dataclass, which serves as the single source of truth for paths, ports, and tunables 1. The configuration resolution follows a strict precedence order: built-in defaults, followed by a TOML file (defaulting to $XDG_CONFIG_HOME/autosre/dropbox.toml or an explicit --config-file path), and finally environment variables prefixed with AUTOSRE_DROPBOX_. This loader is consumed by the proxy, installer, CLI, and tests to ensure uniform behavior.

The proxy relies on several local files for state and credentials, all derived from a base data_dir (default /data/dropbox). These include:

  • TLS Material: cert.pem and key.pem located in the tls_dir.
  • Secrets: An HMAC signing secret (proxy-secret) in the config_dir, generated if missing with mode 0600 to prevent local reading 2.
  • Credentials: The admin password (admin-password) in the config_dir, read on each login attempt.
  • Filebrowser State: The database file (filebrowser.db) in the config_dir 1.

The state_dir is also defined in the configuration but is not explicitly used by the proxy code itself in the provided sources, though it is part of the resolved configuration structure.

The proxy listens on a single port (default 8443) and performs “stealth” TLS handling by peeking at the first byte of every accepted TCP connection 3. If the first byte is 0x16 (TLS ClientHello), the connection is wrapped in an SSL context and processed as TLS. If the first byte is anything else, the connection is treated as plain HTTP, and the proxy responds with a 301 Moved Permanently redirect to the HTTPS version of the requested URL.

The proxy is designed to be “stealthy”: it sends no Server header, omits body content on errors, and presents a minimal login page consisting only of a password input field with no labels, CSS, or title.

Authentication is handled via an HMAC-signed cookie. Upon a successful POST to /__auth with the correct password, the proxy issues a cookie named dbx containing an expiration timestamp and an HMAC-SHA256 signature 2. Subsequent requests are validated by verifying this cookie against the local secret file.

Authenticated requests are reverse-proxied to the upstream filebrowser instance running on 127.0.0.1 at upstream_port (default 18443) 1. The proxy streams request bodies verbatim to the upstream, preserving Transfer-Encoding headers to support large uploads without buffering entire files in memory 2. It strips hop-by-hop headers (e.g., Connection, Keep-Alive) before forwarding.

An unauthenticated health probe endpoint is available at /_health. This endpoint performs an internal HEAD request to the upstream filebrowser. It returns 204 No Content if the upstream responds, or 503 Service Unavailable if the upstream is unreachable or times out. This endpoint is used by kubelet exec probes for readiness and liveness checks.

The proxy is designed to be run as a systemd service, with the configuration loader supporting an explicit --config-file argument or the AUTOSRE_DROPBOX_CONFIG_FILE environment variable, allowing systemd units to point to a runbook-installed TOML file 1. The service binds to 0.0.0.0 by default, making it accessible from outside the host.

In a k3s environment, the proxy runs on the node and exposes the filebrowser service. The health probe endpoint (/_health) is critical for k3s to monitor the proxy’s health, as it validates both the proxy’s TLS listener and the upstream filebrowser’s availability 2. The proxy’s state (secrets, passwords, TLS certs) is stored on the node’s filesystem, meaning it is not distributed across the cluster but is local to the node running the proxy instance.

diagram