The WebSockets protocol enables applications running inside web browsers to open up two way communications. The SIP over WebSockets protocol extends the SIP and adapts it to support WebSockets.
As a basic security measure web browsers do not allow JavaScript applications to access the low level network stack of PC and mobile operating systems. To get around this, applications that desired two way communications with a server would need to constantly poll the server to see if it had any information waiting. This proved to be very inefficient due to the overhead of HTTP communications and was not practical in situations where many users need to connect to very few servers.
To overcome this, browser plug-ins could be installed to give specific applications a lower level access as long as they had the users consent to install additional software. This solution works but has the potential to introduce security flaws within the browser as well as provide an opportunity for malicious software to be installed on the user’s computer or mobile device. The solution to all of these problems is the WebSockets (WS) protocol [RFC 6455].
WebSockets Protocol
The WebSockets protocol provides a means for applications running inside of web browsers to open up two way communications without the need to install additional software. The handshake is done using the HTTP protocol and leverages existing HTTP infrastructure. After the handshake is finished the JavaScript application is allowed to send and receive messages to and from the server without the need for constant polling. These messages are broken up into frames and take a similar path to that of HTTP messages allowing them to travel through the same proxies. This entire process can also take place over a secure HTTP connection (HTTPS) resulting in a secure WebSockets connection (WSS).
Allowing an application access to lower-level sending and receiving of messages opens up some vulnerabilities that are taken care of by the protocol. For example, the application can craft messages in such a way that they can trick HTTP middle boxes into thinking that they are HTTP requests.
This vulnerability is handled by masking the data in the packet with a randomly generated array of bytes. The value of the mask is sent to the peer so that they can unmask the packet. This prevents an application from knowing what the byte stream will look like when it gets to the network and thus prevent it from manipulating the data to produce undesired results.
SIP over WebSockets Protocol
The WebSocket protocol defines an additional HTTP header to be used during the opening handshake. the Sec-WebSocket-Protocol header field is used to specify a WebSocket sub-protocol to be used on top of the WebSocket layer. These protocols can be proprietary or based on a standard. One such standard is SIP over WebSockets [RFC 7118].
The SIP over WebSockets protocol takes the original SIP protocol [RFC 3261] and makes a few modifications to adapt it to WebSockets environments. The major changes from the original SIP specification are the addition of cookie based authentication facilitated by the web browser, and the removal of the requirement for middle boxes to add the received parameter to the header field. This requirement was removed because it could reveal sensitive information about the internal HTTP proxies, servers, load balancers, etc. of networks transporting SIP over WebSockets.
VOCAL’s solution is available for the above platforms. Please contact us for specific supported platforms.
