WebSocket Servers & Gateways: The safer way to serve
We have all heard of VPN's. You start your client, enter credentials and your connected. The problem with this setup is the nature of a VPN.
A VPN provides a secure tunnel but herein lies the issue. It's a full bi-directional tunnel and ALL traffic traverses that tunnel. But what if you only need to provide access to a single application, service, etc.? A VPN opens all communication not just to that specific service or application.
Before we dive too much more into the subject, let me provide a quick overview of Websocket Servers and Gateways. Keep in mind: HTML 5 is a critical part of this equation.
HTML5 WebSockets account for network hazards such as proxies and firewalls, making streaming possible over any connection, and with the ability to support upstream and downstream communications over a single connection, HTML5 WebSockets-based applications place less burden on servers, allowing existing machines to support more concurrent connections. The following figure shows a basic WebSocket-based architecture in which browsers use a WebSocket connection for full-duplex, direct communication with remote hosts.
One of the more unique features WebSockets provide is its ability to traverse firewalls and proxies, a problem area for many applications. Comet-style applications typically employ long-polling as a rudimentary line of defense against firewalls and proxies. The technique is effective, but is not well suited for applications that have sub-500 millisecond latency or high throughput requirements. Plugin-based technologies such as Adobe Flash, also provide some level of socket support, but have long been burdened with the very proxy and firewall traversal problems that WebSockets now resolve.
A WebSocket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT technique. Note that WebSockets are just beginning to be supported by modern browsers (Chrome now supports WebSockets natively). However, backward-compatible implementations that enable today's browsers to take advantage of this emerging technology are available.
1) WebSocket Emulation for older browsers: while most modern browsers support WebSockets natively, the majority of browsers out there are older without any WebSocket support.
2) Traversing proxies, firewalls, and load balancing routers: the WebSocket communication is very often interrupted by hostile network intermediaries.
3) Security: when running your business over the Web, security is paramount.
4) Client technologies: while more and more applications are moving to the Web and HTML5, in addition to JavaScript, look for support for a wide variety of other client technologies: Java/Java FX, Flash/Flex, and Silverlight/.NET.
5) Enterprise robustness: Look for clustering for high availability, ability to perform its own load balancing, and supports disaster recoverability.
6) Higher level protocols: Look for the following -- JMS (can run against any back-end JMS message broker), AMQP, and XMPP.
But you might say, "hey this sounds a lot like REST". You are correct in a manner of speaking but let me offer this. REST and WebSocket communication are two different types of distributed computing plumbing. REST is the old-school, sit on top of HTTP, synchronous style of web RPC. WebSocket is the newer, sit along side HTTP, usually asynchronous style of web communication. WebSockets will dramatically reduce the need for REST for WAN computing. With WebSockets, all the protocols we’ve known and loved for the past few decades can now be extended over the web without the clumsy and performance-deprecating mapping to HTTP.
So this is a security blog, so let's discuss security.
Remember this is not something you get for free: each WebSocket gateway/server needs to implement any of these they consider important.
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 method is that if you know how to configure HTTPS for encrypted communication, then you also know how to configure WSS for encrypted WebSocket communication.
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.
A VPN provides a secure tunnel but herein lies the issue. It's a full bi-directional tunnel and ALL traffic traverses that tunnel. But what if you only need to provide access to a single application, service, etc.? A VPN opens all communication not just to that specific service or application.
Before we dive too much more into the subject, let me provide a quick overview of Websocket Servers and Gateways. Keep in mind: HTML 5 is a critical part of this equation.
HTML5 WebSockets
The HTML5 WebSockets specification defines an API that enables web pages to use the WebSockets protocol for two-way communication with a remote host. It introduces the WebSocket interface and defines a full-duplex communication channel that operates through a single socket over the Web. HTML5 WebSockets provide an enormous reduction in unnecessary network traffic and latency compared to the unscalable polling and long-polling solutions that were used to simulate a full-duplex connection by maintaining two connections.HTML5 WebSockets account for network hazards such as proxies and firewalls, making streaming possible over any connection, and with the ability to support upstream and downstream communications over a single connection, HTML5 WebSockets-based applications place less burden on servers, allowing existing machines to support more concurrent connections. The following figure shows a basic WebSocket-based architecture in which browsers use a WebSocket connection for full-duplex, direct communication with remote hosts.
A WebSocket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT technique. Note that WebSockets are just beginning to be supported by modern browsers (Chrome now supports WebSockets natively). However, backward-compatible implementations that enable today's browsers to take advantage of this emerging technology are available.
What to look for
Here are some things you should look for in your WebSocket platform:1) WebSocket Emulation for older browsers: while most modern browsers support WebSockets natively, the majority of browsers out there are older without any WebSocket support.
2) Traversing proxies, firewalls, and load balancing routers: the WebSocket communication is very often interrupted by hostile network intermediaries.
3) Security: when running your business over the Web, security is paramount.
4) Client technologies: while more and more applications are moving to the Web and HTML5, in addition to JavaScript, look for support for a wide variety of other client technologies: Java/Java FX, Flash/Flex, and Silverlight/.NET.
5) Enterprise robustness: Look for clustering for high availability, ability to perform its own load balancing, and supports disaster recoverability.
6) Higher level protocols: Look for the following -- JMS (can run against any back-end JMS message broker), AMQP, and XMPP.
But you might say, "hey this sounds a lot like REST". You are correct in a manner of speaking but let me offer this. REST and WebSocket communication are two different types of distributed computing plumbing. REST is the old-school, sit on top of HTTP, synchronous style of web RPC. WebSocket is the newer, sit along side HTTP, usually asynchronous style of web communication. WebSockets will dramatically reduce the need for REST for WAN computing. With WebSockets, all the protocols we’ve known and loved for the past few decades can now be extended over the web without the clumsy and performance-deprecating mapping to HTTP.
So this is a security blog, so let's discuss 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.
WebSocket Uses the Same Encryption as HTTPS (TLS/SSL)
You configure TLS (also known as SSL) encryption for WebSocket wire traffic the same way you do for HTTP, using certificates.The benefit of this method 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.Certificates
You can customize endpoint connections using intermediate certificates if you choose to self-sign your own client certificates. The options are there to customize which allows importation and validation of self-signing.Summary
A WebSocket application can be made secure because various standards provide for that possibility. And since WebSocket is HTTP-compatible, it benefits from many of the same security techniques that can be applied to HTTP.
It is up to each WebSocket gateway/server to implement some or all of these standard security protections. Just like you would pick a web server or application server with the security features you need, you need to pick a WebSocket gateway/server with the security features you need.
Any WebSocket vendor that only has a few or none of them is not serious about security.
If you are building a real-world or enterprise WebSocket-based application then think about your security needs early. It’s not something you want to “bolt on” later because that will mean having to change your architecture or write a lot of extra code.
An enterprise WebSocket gateway/server will have security built into the architecture that you can simply configure when you’re ready. Because when you don’t take security seriously, your customers won’t take you seriously.
Comments
Post a Comment