Secure WebSocket Connection

The WebSocket version uses WSS (WebSocket Secure) over TLS/SSL for every connection. Authentication tokens are generated server-side and validated on each connection, so only authorized users can subscribe to messaging channels. The WebSocket relay only forwards encrypted event data — it never has access to decrypted message content.

WebSocket version

This is a transport-layer security feature. The free version doesn't use WebSocket; AJAX runs over your own site's HTTPS.

What it adds#

WSS encryption for all WebSocket connections (TLS 1.2+ / 1.3)
Server-side authentication tokens validated on every connection
Unauthorized connection attempts rejected with detailed error codes
Message content AES-256 encrypted before transmission (see Private)
WebSocket relay cannot read message content or metadata
Fresh authentication handshake on every reconnection (post-network-drop)

How it works#

When a user opens a page with the messenger, the JavaScript client requests an authentication token from your WordPress server. The server validates the user's WordPress session, generates a short-lived signed token, and returns it. The client then opens a WSS connection to the cloud relay, passing the token. The relay verifies the token's signature and grants access.

Step	Security guarantee
WordPress auth (cookie)	Standard WordPress session security
Token generation on your server	Token is signed; only your server can mint valid tokens
WSS handshake to the relay	TLS encryption of the connection setup
Token validation by relay	Cryptographically verifies the user has WordPress access
Message routing	Only encrypted ciphertext forwarded between participants
Reconnect after network drop	Fresh token re-issued by your server

Defense layers#

Layer	Threat protected against
WSS (TLS)	Network eavesdropping, man-in-the-middle attacks
Signed token	Unauthorized users impersonating others
Token expiration	Stolen tokens become useless quickly
Per-channel ACL	Users can only subscribe to channels they belong to
AES-256 content encryption	Relay-level data breach can't reveal message content

Frequently asked questions#

What TLS version is used?#

TLS 1.2 minimum, with TLS 1.3 negotiated when both client and server support it (modern browsers all do). Cipher suites use modern algorithms (AEAD, forward secrecy).

How long are authentication tokens valid?#

Short-lived — typically 1 hour. The client transparently refreshes them before expiry, so users never see a re-authentication prompt.

No — channels are guarded by signed token claims. Even if a user knows the channel ID, the relay only accepts subscriptions for channels included in the user's token claims. The server only mints tokens with channels the user is actually a participant in.

What happens if my WordPress site uses HTTP (not HTTPS)?#

The WebSocket version requires HTTPS on your WordPress site. WSS-to-mixed-content rules in browsers would block the connection otherwise. WSS is hard-required.

Is this enough to claim PCI compliance / HIPAA compliance?#

Transport encryption is necessary but not sufficient. For PCI / HIPAA, also consider end-to-end encryption, the self-hosted plan, message retention policies, and access controls. Discuss specific compliance requirements with support.