The OpenLiteSpeed Features Keep Coming: WebSocket Proxy + OCSP Stapling

OpenLiteSpeed is giving us the chance to add and test a horde of new features. For 1.2 (which came out today!), we’ve added WebSocket proxies and OCSP stapling. Both of these are exciting features that should speed up the Internet (as soon as they’re widely integrated into the Internet).

WebSocket Proxies

WebSocket changes the way the Internet works: It is a protocol that allows the server and the client can have a bidirectional conversation. The client doesn’t just request content from the server. The server also sends content to the client whenever there’s content to be sent (without waiting to be asked). This bidirectional conversation allows for realtime web experiences. While HTTP tries to simulate real time interaction at great expense (through incessant refreshing), WebSocket makes realtime interaction a reality. This upgrades all sorts of web applications: stock tickers, data center monitors, news feeds… But probably the most exciting feature of realtime Internet is the ability for multiple users to see and react to things they each do in real time. I’m not sure that there has really been a revolutionary WebSocket application yet (though the Kaazing people probably beg to differ), but there are some pretty cool things out there: I really like Rumpetroll and WordSquared and there’s some interesting things in the Mozilla Demo Studio. My favorite idea is collaborative drawing with strangers, but I haven’t seen anywhere that’s really active.

In all honesty, you don’t need LiteSpeed to run WebSocket applications. You could simply set up a WebSocket backend on a different port and have WebSocket traffic linked to that port. Using the WebSocket proxies in OpenLiteSpeed, though, allows you to control incoming connections with OpenLiteSpeed’s connection handling and security features. It also gives you the advantage of being able to serve different kinds of content on the same page with different backends. If the page that contains your WebSocket application also has static content or PHP, you could have the WebSocket backend serve that content, but it’s not really optimized to do so. Look again at the Kaazing demo. That’s not just WebSocket. With a WebSocket proxy in OpenLiteSpeed, traffic that has the HTTP WebSocket upgrade request is forwarded to the WebSocket backend, while other traffic can be handled by another context. In addition to having a WebSocket proxy, your page can be part of an LSAPI context so OpenLiteSpeed can serve the PHP on the page, or a static context so OpenLiteSpeed will serve the static content on the page, all while forwarding traffic with the HTTP upgrade request to the WebSocket backend. Just go to the WebSocket tab (in the WebAdmin console, under the virtual host configurations) and set the URI for your page and the address of the WebSocket application. (You can set up any other contexts you would like this URI to be part of in the Context tab.) OpenLiteSpeed will handle the rest.

Update: Guide to setting up a WebSocket proxy.

OCSP Stapling

OCSP and OCSP stapling don’t change the Internet’s basic functionality. They just streamline an existing process by helping the client out a little. In the bad old days (and often now as well), a client validates a secure site by checking the server’s certificate against a certificate revocation list (CRL). This list contains every certificate that the certificate authority (CA) has declared invalid. This means every time a client accesses a secure site they have to run through the whole list of bad certificates (which can get quite long). OCSP speeds up this process by having the client ask an OCSP responder (a server) about a particular certificate when they want to access a secure site. The OCSP responder only returns information about this certificate, which means there’s much less information for the client to parse.

OCSP stapling takes all this one step further by having the web server take control of the process: The server contacts the OCSP responder at regular intervals to download a response verifying the server’s certificate. When the server then receives the first part of a client’s SSL handshake, the server responds with its certificate and the OCSP response attached (stapled on). Now the client gets the certified certificate in one step. They don’t have to start up a connection to another server to ask about it. They don’t have to parse a whole long list. They don’t even have to request the certificate — it’s there in the handshake. And the CA doesn’t have to field non-stop verification requests. The whole Internet is more efficient.

All you need to do to set up OCSP stapling is enable it, put in the address of your OCSP responder, and the location of your OCSP CA certificates file (a file containing the certificates from the CA that your server uses to validate the responses you get from the OCSP responder. Yes, that is a lot of validating and certifying, but it’s way simpler than checking the whole list of bad certificates to make sure you didn’t just get one.)

LiteSpeed is faster than ever! Move the Internet forward. Get it now.