HTML and CSS Reference
In-Depth Information
WebSocket
native
defence
mechanisms
By default, the WebSocket protocol is designed to be secure. In the real world, you
might encounter various issues that might occur due to poor browser implementation.
No need to worry though. As time goes by, browser vendors fix any issues immedi-
ately, and if you still feel afraid, you can always use some old-school fallback tech-
niques (described in the next chapter).
SSH/TLS
As you have probably guessed, an extra layer of security is added when you use
secure WebSocket connection over SSH (or TLS). Remember when you needed to
decide between HTTP and HTTPS? You picked HTTPS only when it was absolutely
necessary for your transactions (for example, bank account information, private data,
and so on). Otherwise, HTTP was the way to go, as it is more lightweight and fast.
HTTPS required more CPU resources and was quite slower than HTTP.
In the WebSocket world, you do not need to worry about the performance of a secure
connection. Although there is still an extra TLS layer on top, the protocol itself con-
tains optimizations for this kind of use, furthermore, WSS works more sleekly through
proxies.
Client-to-Server masking
Every message transmitted between a WebSocket server and a WebSocket client
contains a specific key, named masking key , which allows any WebSocket-compliant
intermediaries to unmask and inspect the message. If the intermediary is not
WebSocket-compliant, then the message cannot be affected. Masking is handled by
the browser that implements the WebSocket protocol.
Search WWH ::




Custom Search