OpenClaw iOS TLS Hardening: Forcing Encryption for Remote Gateways

A new fix ensures OpenClaw's iOS app always uses TLS when connecting to non-loopback gateway addresses — closing a gap where manual configuration could inadvertently allow unencrypted connections to remote servers.

About the Author

Mariano is a mobile security contributor to the OpenClaw project, focusing on iOS and watchOS implementations. This fix is part of a broader effort to harden OpenClaw's mobile apps for enterprise deployment.

The Vulnerability

OpenClaw allows users to manually configure gateway hosts for advanced setups — self-hosted gateways, custom deployments, or enterprise installations. The iOS app accepted these configurations without validating that remote connections used TLS.

This meant a user could accidentally (or be tricked into) configuring an HTTP connection to a remote gateway, sending authentication tokens and conversation data in plaintext across the network.

Threat model: On public WiFi or compromised networks, an attacker could intercept gateway traffic, capture auth tokens, and hijack AI assistant sessions. Given that AI assistants often handle sensitive queries (calendars, emails, documents), this exposure matters.

The Fix

Commit 8fa46d7 implements a straightforward rule:

Loopback addresses (127.0.0.1, localhost, ::1): HTTP allowed — you're connecting to yourself
Everything else: TLS required — the app upgrades to HTTPS or rejects the connection

// Simplified logic
if (!isLoopbackAddress(gatewayHost)) {
    requireTLS = true;
    if (scheme != "https") {
        scheme = "https";  // Force upgrade
    }
}

Why This Approach

The fix is intentionally simple:

No exceptions: You can't configure your way around it. If it's not localhost, it's encrypted.
Auto-upgrade: Rather than error out, the app fixes the scheme automatically — reducing user friction
Localhost allowed: Local development and self-hosted gateways on the same device still work without certificates

Broader Context

This fix comes amid a week of security hardening in OpenClaw:

Multiple pairing and onboarding fixes to preserve operator scopes
OAuth synchronization improvements across agents
Web login retry failure handling
Background refresh configuration for iOS

The pattern is clear: as OpenClaw matures beyond hobbyist use into enterprise and professional contexts, security gaps that were acceptable in early releases become blockers. This TLS fix is a good example — technically optional when everyone runs localhost, but essential when remote gateways enter the picture.

For Users

If you're running OpenClaw with a custom gateway configuration:

Localhost setups: No change required
Remote gateways over HTTP: Update to iOS 4.2+ and your configuration will auto-upgrade to HTTPS
Self-signed certificates: You may need to configure certificate pinning or add your CA to the trust store

Source: openclaw/openclaw@8fa46d7