WebSocket Secure (wss://)

WebSocket Secure (wss://) is the encrypted variant of the WebSocket protocol. A wss:// connection wraps the WebSocket handshake and all subsequent frames inside a TLS tunnel, providing confidentiality, data integrity, and server Authentication. The wss scheme is defined alongside ws in the WebSocket protocol specification.

Usage

Most production WebSocket deployments use the wss scheme. The security properties are the same as those provided by HTTPS: traffic between client and server is encrypted, preventing eavesdropping and tampering by intermediaries.

The default port for wss:// connections is 443, the same port used by HTTPS. This alignment with existing TLS infrastructure means wss:// connections pass through corporate firewalls and proxy servers already permitting HTTPS traffic.

How the connection is established

A wss:// connection follows a three-step sequence:

1. TCP connection. The client opens a TCP connection to the server on port 443 (or a configured port).
2. TLS handshake. The client and server negotiate a TLS session. The server presents a certificate, and the client validates the certificate against trusted certificate authorities.
3. WebSocket handshake. Inside the encrypted TLS tunnel, the standard WebSocket opening handshake proceeds using the Upgrade mechanism (HTTP/1.1) or the extended CONNECT method (HTTP/2, HTTP/3).

All WebSocket frames after the handshake travel through the encrypted tunnel.

TLS requirements

The specification mandates TLS for all wss:// connections. When the secure flag is set, the client must perform a TLS handshake before sending any WebSocket data. All communication after the handshake runs through the encrypted channel.

Clients must include the Server Name Indication (SNI) extension in the TLS handshake, allowing the server to present the correct certificate when hosting multiple domains on a single IP address.

URI

The wss URI scheme follows the same structure as the ws scheme, with the protocol identifier changed to indicate an encrypted connection.

wss://authority/path?query

Improved reliability

The wss scheme improves connection reliability beyond security. Some proxy servers do not recognize the ws scheme and terminate or drop WebSocket upgrade requests. Because wss traffic is encrypted, proxies treat the connection as opaque TLS and pass the data through without inspection or interference.

Example

An encrypted WebSocket connection opened through the browser API in JavaScript. Event and error handling follow as needed.

const connection = new WebSocket(
  'wss://files.example.re/'
);

A Node.js server accepting wss:// connections requires TLS certificate and key files.

const { WebSocketServer } = require('ws');
const https = require('https');
const fs = require('fs');

const server = https.createServer({
  cert: fs.readFileSync('/path/to/cert.pem'),
  key: fs.readFileSync('/path/to/key.pem')
});

const wss = new WebSocketServer({ server });
server.listen(443);

Takeaway

WebSocket Secure (wss://) encrypts all WebSocket communication using TLS, providing the same confidentiality and integrity guarantees as HTTPS. The connection sequence is TCP, then TLS handshake, then WebSocket handshake inside the encrypted tunnel. Most production deployments use wss for both security and improved compatibility with network intermediaries.

See also

• RFC 6455: The WebSocket Protocol
• WebSocket
• HTTPS
• Uniform Resource Identifier
• WebSocket Protocol Registries
• HTTP headers