An HTTPS address describes the browser’s protected connection, not every later connection to the application.
In Fibmesh Publish, browser HTTPS terminates at the public gateway. WireGuard protects the next hop to the connector, where that tunnel protection ends. The connector’s HTTP or HTTPS connection to the application is separate; a plaintext local area network (LAN) hop stays plaintext unless it has its own protection.
These boundaries determine which components handle decrypted data and which service identities must be checked. Trace each connection before describing the whole application path as encrypted.
Browser → public gateway → connector → application
- BrowserHTTPS to the public gateway; check its hostname certificate.
- Public gatewayHTTPS terminates. Decrypted requests enter the WireGuard leg.
- ConnectorWireGuard terminates. A separate HTTP or HTTPS connection begins.
- ApplicationFor HTTPS, validate the application’s own service identity.
Illustrative Publish connection. HTTPS ends at the gateway; WireGuard ends at the connector. A separate HTTPS connection can protect the final hop. Earlier encryption does not protect a later plaintext LAN hop.
HTTPS terminates at the public gateway
Consider Fibmesh Publish, available with assisted setup. The browser connects to the public gateway over HTTPS. The gateway presents the certificate for the public hostname and terminates the HTTPS session.
Termination means the gateway can process the decrypted HTTP request. It can select the intended publication and forward the request through the approved path. The gateway is therefore part of the trust boundary for the application data it handles.
This is not a continuous Transport Layer Security (TLS) session from the browser to the customer application. Calling the whole path “end-to-end encrypted” would obscure that distinction. MDN’s TLS explanation describes protection and authentication between the participants in a TLS connection; identifying those participants is essential.
WireGuard encryption ends at the connector
The gateway-to-connector transport uses WireGuard in the Publish design. It protects traffic between those tunnel peers. At the connector, that protection ends and the request continues through the application-forwarding process.
The WireGuard overview explains its encrypted packet transport and peer model. A tunnel carrying an application request does not automatically extend its encryption to another machine beyond the receiving peer.
Suppose the connector runs on a separate device in an office. The application runs on a server on that office LAN. If the connector opens a plaintext HTTP connection to that server, the LAN hop remains plaintext. Earlier HTTPS and tunnel protection do not change that fact.
Protect the connector-to-application connection
A connector can also run on the same host as the application. HTTP to a loopback listener then has a different exposure from HTTP sent across a shared LAN. Assess the actual processes, host protections and application requirements instead of describing both arrangements simply as “internal.”
localhost belongs to the machine or network namespace using it. Entering it as a target on a connector elsewhere does not refer to the application server you had in mind. Verify the target from the connector’s environment.
For an HTTPS application connection, the connector needs the intended server identity and a valid trust configuration. A private address or internal certificate does not justify ignoring certificate errors. The IETF’s Service Identity in TLS specification describes verifying that the presented identity matches the expected service.
Arrange the target name, certificate and trust deliberately. If those do not match, fix the arrangement. An “accept any certificate” workaround removes a check that helps distinguish the intended application from an impostor.
Keep application authentication separate from encryption
A protected transport does not decide which account may read an invoice or modify a record. The application still needs to authenticate callers and enforce its own permissions.
In Publish, the application handles visitor accounts or API credentials. Richer managed visitor gates remain planned extensions. A successfully routed request is not evidence that the caller is authorized to perform the requested operation.
Keep the same distinction for machine requests. A webhook signature, for example, has a different purpose from the HTTPS connection carrying it. The receiver must apply the provider’s verification rules before acting on the event.
Audit every connection, certificate and plaintext boundary
For each segment, write down the sender, receiver, protection and identity check. A useful record might identify browser-to-gateway HTTPS, gateway-to-connector WireGuard and connector-to-application HTTPS with validation against the chosen application name.
Then mark the places where plaintext exists during normal processing. Include the gateway, connector and application according to their actual forwarding behavior. Review what those components record: transport encryption does not prevent a component from writing a sensitive header or body into its own logs.
Keep private keys, access tokens and other secrets out of diagnostics. Assign owners for the public certificate and any separate application certificate, including renewal and failure handling. One certificate being healthy does not prove the other is.
When reviewing a design, follow one request all the way to the application and its response back. The result should be a specific account of each protected connection and trusted component. That is much more useful than coloring the entire route green and assuming the question has been answered.
