Reverse Proxies & TLS
What is a Reverse Proxy?
A reverse proxy is a server that sits between client devices (such as web browsers or API consumers) and one or more backend servers, intercepting and forwarding requests on behalf of the backend. When a user navigates to a URL, the connection is established with the reverse proxy rather than directly with the server that actually hosts the application or service. The reverse proxy then determines how to handle the request - it may forward it to a backend server, reject it based on security rules, cache the response, or modify the request headers - before relaying the response back to the user. The user is typically unaware that a reverse proxy is involved; from their perspective, communication occurs directly with the domain entered in their browser. Reverse proxies are one of the most fundamental building blocks of modern internet infrastructure, used by virtually every major web service in the world. They exist for several critical reasons. First, security and isolation: by placing a reverse proxy in front of backend services, the outside world is prevented from directly reaching the servers. The proxy is the only point of contact, and it can filter, inspect, and reject malicious traffic before it ever reaches the application. Second, TLS termination: the reverse proxy can handle the computationally expensive work of encrypting and decrypting HTTPS traffic, meaning the backend service can operate on plain HTTP internally while the public-facing connection remains encrypted. Third, access control: the proxy can enforce authentication, authorization, IP filtering, rate limiting, and other access control policies before forwarding traffic. Fourth, abstraction: the proxy decouples the public-facing URL from the internal network topology. A backend service may be running on a private IP address at an arbitrary port behind multiple layers of networking - the reverse proxy maps a clean public domain to that internal address.
How Horizon Uses Reverse Proxying
Horizon is, at its core, a managed reverse proxy service purpose-built for the Mutexer platform. Each circuit in Horizon corresponds to a reverse proxy route: the public domain {prefix}.horizon.mutexercloud.com is the entry point, and the internal IP:Port on the agent-connected device is the backend target. When a request arrives at the circuit's domain, the Horizon proxy - running on Mutexer's cloud infrastructure - handles the entire lifecycle of that request. It terminates the TLS connection (decrypting the incoming HTTPS traffic), checks the access policy, evaluates IP rules and country blocks, and if the request passes all checks, forwards it through the Core API to the Mutexer Agent running on the device. The Agent then delivers the request to the target service at the specified internal IP and port, using whichever protocol (HTTP or HTTPS) was configured for the circuit. The response from the backend service travels the reverse path back through the Agent, through the proxy, and is re-encrypted over HTTPS before being delivered to the user. This entire process is transparent to both the end user and the backend service - the user simply sees a normal HTTPS website, and the backend service simply receives a normal HTTP or HTTPS request.
What is TLS Termination?
TLS (Transport Layer Security) is the cryptographic protocol that provides the "S" in HTTPS. When a browser connects to an HTTPS website, TLS ensures that the communication between the browser and the server is encrypted, preventing anyone who intercepts the network traffic from reading or modifying it. TLS termination is the process of decrypting incoming TLS-encrypted traffic at a specific point in the infrastructure - typically at the reverse proxy - rather than at the backend server itself. This is important for several reasons. The computational overhead of TLS encryption and decryption is non-trivial, and offloading this work to a dedicated proxy server means that backend services (which in Horizon's case are often resource-constrained industrial devices) do not need to bear this burden. It also means that TLS certificate management - obtaining certificates, renewing them before they expire, and configuring them correctly - is handled centrally by the platform rather than requiring each device operator to manage certificates individually. In Horizon, TLS termination happens at the Horizon proxy layer. All public-facing traffic is encrypted with HTTPS. The connection between the Horizon proxy and the backend device uses whichever protocol was selected when creating the circuit (HTTP or HTTPS), depending on whether the backend service is configured to handle TLS itself. In most industrial scenarios, the backend service runs on plain HTTP, and the Horizon proxy provides the encryption layer for the public-facing side.
TLS 1.3 Only
Horizon exclusively supports TLS 1.3 for all public-facing connections. Older protocol versions - TLS 1.2, TLS 1.1, TLS 1.0, and all versions of SSL - are explicitly rejected at the proxy layer. If a client attempts to connect using any protocol version older than TLS 1.3, the connection is refused before any application data is exchanged. This is a deliberate and opinionated design decision rooted in the security requirements of industrial automation environments, where the consequences of a compromised connection can extend beyond data loss to physical safety and operational continuity.
TLS 1.3, published as RFC 8446 in August 2018, represents a fundamental redesign of the TLS handshake and cryptographic architecture compared to its predecessors. TLS 1.2 and earlier versions supported a large number of cipher suites - many of which are now considered weak or broken - and the protocol allowed the client and server to negotiate which algorithms to use during the handshake. This flexibility was a liability: it meant that a misconfigured server could agree to use a weak cipher, and that downgrade attacks (where an attacker forces the connection to use an older, weaker protocol version) were a real and actively exploited threat. Notable attacks exploiting weaknesses in TLS 1.2 and earlier include BEAST, CRIME, POODLE, Logjam, FREAK, and Sweet32, each of which targeted specific cipher suites, compression mechanisms, or protocol features that TLS 1.2 permitted. TLS 1.3 eliminates these attack surfaces entirely by removing support for all legacy cryptographic algorithms that have known weaknesses. There is no RSA key exchange, no CBC-mode ciphers, no RC4, no SHA-1, no static Diffie-Hellman, no custom DHE groups, and no compression - all of which were vectors for past attacks. The only cipher suites available in TLS 1.3 are modern, authenticated encryption with associated data (AEAD) algorithms: AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305. The handshake itself was redesigned to complete in a single round trip (1-RTT) instead of the two round trips required by TLS 1.2, meaning connections are established faster while being more secure. TLS 1.3 also supports zero round trip time resumption (0-RTT) for repeat connections, further reducing latency.
By enforcing TLS 1.3 exclusively, Horizon ensures that every connection to every circuit uses the strongest available encryption and handshake protocol, with no possibility of negotiation downgrade to a weaker version. This is particularly important in industrial environments where devices may be deployed for years or decades, and where the traffic passing through Horizon circuits may include sensitive operational data, control commands, or access to critical infrastructure management interfaces. The tradeoff is that very old clients - specifically, browsers or HTTP libraries that do not support TLS 1.3 - will not be able to connect to Horizon circuits. In practice, this is rarely an issue: TLS 1.3 has been supported since Chrome 70 (October 2018), Firefox 63 (October 2018), Safari 12.1 (March 2019), and Edge 79 (January 2020), meaning all browsers updated in the last six years support it. For programmatic API clients, all major HTTP libraries in Python, Node.js, Go, Java, Rust, and .NET have supported TLS 1.3 for several years.
Perfect Forward Secrecy (PFS)
All connections to Horizon circuits are protected by Perfect Forward Secrecy (PFS), which is enforced as a mandatory property of every TLS session - it cannot be disabled, downgraded, or bypassed. Perfect Forward Secrecy is a cryptographic property that ensures that the compromise of a server's long-term private key does not retroactively compromise the confidentiality of past encrypted sessions. To understand why this matters, consider how key exchange works without forward secrecy. In older TLS configurations that use static RSA key exchange, the client encrypts a session key (called the pre-master secret) using the server's public key, and the server decrypts it with its private key. Both sides then derive the symmetric encryption keys for the session from this shared secret. The problem is that if an attacker records the encrypted traffic and later obtains the server's private key - through a server breach, a compromised backup, a stolen hard drive, a legal compulsion, or any other means - they can retroactively decrypt the recorded pre-master secret, derive the session keys, and read every recorded session in plaintext. This is not a theoretical concern: intelligence agencies and sophisticated attackers are known to record encrypted traffic in bulk with the expectation of decrypting it later when keys become available, a strategy sometimes called "harvest now, decrypt later."
Perfect Forward Secrecy eliminates this risk by using ephemeral key exchange - specifically, Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). In an ECDHE key exchange, the client and server each generate a fresh, temporary (ephemeral) key pair for every single TLS session. They exchange public keys and independently compute a shared secret using the Diffie-Hellman algorithm, without ever transmitting the shared secret over the network. The symmetric encryption keys for the session are derived from this shared secret. Crucially, the ephemeral private keys are discarded as soon as the session keys are derived - they exist only in memory for the duration of the key exchange computation and are never written to disk. As a result, even if the server's long-term private key is compromised at some future date, there is no way to reconstruct the ephemeral keys that were used for past sessions. Each session's encryption keys are independent and cannot be derived from any other session's keys or from the server's long-term key. Every past session remains confidential, even in a total server compromise.
TLS 1.3 makes Perfect Forward Secrecy mandatory by design - it is not an optional feature that can be disabled by server configuration. Every cipher suite in TLS 1.3 uses ECDHE or DHE key exchange, and static RSA key exchange has been removed from the protocol entirely. This is one of the reasons Horizon enforces TLS 1.3 exclusively: in TLS 1.2, PFS was available but not guaranteed, because the protocol still allowed cipher suites with static RSA key exchange. A misconfigured TLS 1.2 server could negotiate a non-PFS cipher suite, silently removing forward secrecy protection without the user or operator being aware. By requiring TLS 1.3, Horizon guarantees that every single connection to every circuit has Perfect Forward Secrecy - there is no configuration that can weaken this, no cipher suite negotiation that can bypass it, and no downgrade attack that can remove it.
For industrial automation environments, where Horizon circuits may provide access to operational technology systems, control interfaces, and sensitive telemetry data, the guarantee of Perfect Forward Secrecy means that even in a worst-case scenario where the platform's TLS private keys are compromised, all previously recorded traffic remains encrypted and unreadable. This is a critical security property for systems that may be subject to nation-state level threats, long-term surveillance, and regulatory requirements around data confidentiality.
Why This Matters for Horizon Users
Understanding the reverse proxy and TLS architecture enables more informed decisions when configuring circuits. Selecting "HTTP" as the protocol for a circuit instructs the proxy to forward the decrypted request to the backend service over plain HTTP, which is appropriate when the backend does not terminate TLS itself. Selecting "HTTPS" instructs the proxy to forward the request over an encrypted connection, which is required when the backend service expects TLS-terminated traffic. In either case, the public-facing domain always uses HTTPS with TLS 1.3 and Perfect Forward Secrecy, ensuring end users always have the strongest available encrypted connection. No manual cipher suite selection, TLS version configuration, certificate provisioning, DNS setup, or any other aspect of TLS infrastructure management is required - Horizon handles all of this automatically and enforces the most secure settings by default, with no option to weaken them. The reverse proxy architecture also means that the backend service is never directly exposed to the internet. All traffic must pass through the Horizon proxy, which applies TLS 1.3 termination, Perfect Forward Secrecy, and every configured security layer before forwarding the request. This provides a strong layer of defense-in-depth even if the backend service itself has vulnerabilities or uses older, less secure protocols internally.
INFO
No manual management of TLS certificates, cipher suites, or proxy software is required when using Horizon. The platform handles all of this automatically for every circuit. All public-facing connections use TLS 1.3 exclusively, with Perfect Forward Secrecy enforced on every session - older protocol versions are rejected.