In the WebSocket protocol, what does a wss: URL give you that a ws: URL does not, and where does that protection stop?

## Two schemes, one protocol `RFC 6455` registers `ws:` and `wss:`. They address the same protocol — the same `Upgrade: websocket` handshake, the same `101 Switching Protocols`, the same frames afterwards — and differ in one respect: a `wss:` connection establishes TLS first and runs everything inside it. The default ports follow the HTTP convention: `80` for `ws:`, `443` for `wss:`. A useful way to hold it: the scheme chooses the *envelope*, never the *letter*. Nothing you know about the handshake, the frame layout or the closing exchange changes because the URL gained a second `s`. ## Where the protection actually stops TLS protects a connection between two endpoints. On a real deployment the client's endpoint is usually **not** your service: - the operator's browser opens `wss://board.example/occupancy`; - an edge terminator inside the municipal network completes TLS and reads the request; - it opens its own connection onward to the service that holds the socket. That second connection is a separate decision. If nobody configured it, it carries the same frames in the clear across the internal network. The learner-visible rule is short: **TLS covers a hop, not a path.** A socket is exactly as confidential as its least protected hop, and the client's URL scheme tells you nothing about the hops it cannot see. | | `ws:` | `wss:` | |---|---|---| | protocol carried | WebSocket | WebSocket, unchanged | | default port | 80 | 443 | | readable by an on-path device | yes | no, up to the termination point | | modifiable in flight | yes | no, up to the termination point | | beyond the termination point | n/a | whatever that hop was configured to do | ## Why the plaintext scheme is the one that gets mangled There is a second, less obvious reason deployments standardise on `wss:`, and it is operational rather than confidential. An intermediary can only interfere with what it can parse. A caching layer, a filtering appliance or a general-purpose proxy that sees a plaintext handshake may: - re-create the request without the connection-scoped upgrade fields, so the upgrade quietly becomes an ordinary request; - try to interpret, buffer or rewrite what follows the handshake, having no idea it is now frames; - apply an ordinary request idle allowance and cut a connection that is healthy but quiet. A hop that is merely carrying an encrypted connection has nothing to re-create and nothing to rewrite. That is why the practical advice — use `wss:` even on a network you consider internal — is defended on two grounds at once: confidentiality, and the far more mundane fact that fewer devices will break the connection. ## What this does not buy you Be precise about the boundaries, because this is where the follow-up lands: 1. **It is not authentication.** TLS tells the client it reached the host named in the URL. It says nothing about which user is on the socket. 2. **It is not a cross-site defence.** A page on any origin can open a `wss:` socket just as easily as a `ws:` one; the scheme has no bearing on who may open the connection. 3. **It does not survive termination.** Encrypted to the edge and plain thereafter is a common shape and an accepted one in some networks — but it is a decision to make explicitly, not a property the scheme grants you end to end. A fourth boundary is worth stating because it is the one that trips people in production: **the scheme is a property of the URL the client used, not a property of the deployment.** A client can be using `wss:` while the frames spend most of their journey in the clear, and a client using `ws:` can be riding an encrypted tunnel a hop set up for it. The only honest description of a deployment is hop by hop. ## On the occupancy board The operator's console connects with `wss:`, so the municipal filtering appliance between the console and the city's edge sees an encrypted connection and passes it through. TLS terminates at the edge; the hop from the edge to the service holding the sockets is configured separately, and whether it is encrypted is a thing an engineer chose and can state. If the answer is "I do not know", the honest description of the deployment is that the board's occupancy feed is encrypted as far as the edge and unknown after it — which is exactly the sentence an interviewer is waiting to hear you able to say.