Unified HTTP and WebSocket Security

Unified HTTP and WebSocket Security

Thanks to the HTTP/WebSocket unified security model, the following is a list of some standard HTTP security methods that can be applied to a WebSocket connection. Remember this is not something you get for free: each WebSocket gateway/server needs to implement any of these they consider important. (Kaazing’s Gateway supports all of them, and more.)

• Same Encryption as HTTPS using TLS/SSL

  You configure TLS (also known as SSL) encryption for WebSocket wire traffic the same way you do for HTTP, using certificates. With HTTPS, the client and server first establish a secure envelope (connection) and only then begin the HTTP protocol. In exactly the same way, WebSocket Secure (WSS) first establishes a secure envelope, then begins the HTTP handshake, and then the upgrade to the WebSocket wire protocol.
  In other words, just like HTTPS is not really a different protocol but is HTTP transported over TLS, WSS is not a different protocol but is WS (WebSocket) transported over TLS.
  The benefit of this is that if you know how to configure HTTPS for encrypted communication, then you also know how to configure WSS for encrypted WebSocket communication.
  

• Origin-based Security

  Just like HTTP, a WebSocket endpoint is defined by a URL which means origin-based security can be applied (as you would for HTTP). WebSocket always uses the origin security model, as defined by RFC 6454. If your WebSocket gateway/server can be configured for origin-based access control then you can do cross-origin WebSocket connections in a secure way.
  Cross-origin communication has traditionally been a bane of Web development because it opens the door to malicious cross-scripting attacks. But thanks to the standard origin security model it can now be done securely. This is another good example of an HTTP security capability that can also apply to WebSocket due to being HTTP-compatible.
  Be sure to pick a WebSocket gateway/server which supports origin-based security because it lets you partition your application over different hosts or even domains, giving you architectural flexibility. (Or perhaps you want a WebSocket-based service that other sites can access securely, such as for mashup applications).
  Just like existing HTTP Ajax/Comet applications, without cross-origin support you are constrained to either having your WebSocket connection forced to connect to the same origin only or you have to endure security risks when making cross-origin connections.

• Cookie-based Interaction Pattern

  It is common for applications to store session information in cookies. When connecting to a server it can validate the payload of the cookie and let users proceed without continually forcing them to enter their credentials.
  If you already use cookies for existing Web applications there’s no reason a WebSocket gateway/server can’t read the same cookies for session management.

Incidentally, given that Kaazing was a major contributor to the original WebSocket wire protocol specification, many of these security benefits derive from Kaazing’s submissions to the standard.

Native WebSocket Security

Here are some non-HTTP-related security features defined by the WebSocket standard itself.

• Subprotocol Validation

  The WebSocket protocol was designed as a transport layer for higher-level protocols (just like TCP, but for the Web). For example, you can transport existing protocols like XMPP, AMQP, Stomp, and so on over the Web, through firewalls and proxies, using the standard ports 80/443.
  The Sec-WebSocket-Protocol header specifies what subprotocol (the application-level protocol layered over the WebSocket protocol) is negotiated between the client and the WebSocket gateway/server.
  A WebSocket connection can navigate through HTTP communication ports advertising the shape of the protocol that is going to be spoken on top of WebSocket. Therefore a gateway/server, or intermediaries, can properly assess that the traffic flowing is compliant or put security policies in place.
  This protocol-level inspection allows security policies to go deeper than typical HTTP packet-level inspection. The kind of deep packet inspection usually reserved for LANs and WANs now applies equally well over the Web with WebSocket.
  This is one of the advantages of using WebSocket as a transport layer for higher-level protocols over simply sending proprietary messages directly over the WebSocket connection.

• Client-to-Server Masking

  Each WebSocket frame—think of a frame as a message—is automatically masked to prevent old or badly-implemented intermediaries from accidentally or deliberately causing issues based on bytes in the payload. Unlike HTTP, code on the client cannot successfully predict the precise bytes used to represent the payload of messages sent to the WebSocket gateway/server.
  Each frame contains the masking key so WebSocket-aware intermediaries can unmask the messages for protocol or packet inspection, or to enforce security policies, and so on.