Click here to Skip to main content
Click here to Skip to main content

Secure Spike Engine Websockets with TLS/SSL

, 10 Jun 2014 CPOL
Rate this:
Please Sign up or sign in to vote.
Securing Spike Engine HTTP & Websockets with TLS/SSL layer.

Overview

This article shows how to secure a Spike-Engine channel using SSL/TLS security layer. This allows to transmit HTTP and WebSocket information in a secure fashion. I’m going to assume that the reader is already familiar with Spike-Engine and I’m going to explain the setup process for a simple secure communication via websockets. 

Other Spike Engine Articles

Creating the Certificate

First of all, we are going to create a self-signed certificate for our example purposes. While there are many ways to do so, I’ve found Pluralsight’s great utility that allows to create one just in one click.

Once we’re done with the certificate, we should create a .PFX file, this file contains the private key and allows the server to be authenticated as one. We’ll save the certificate in the Data folder of our server, simply telling Visual Studio to publish it as content. Spike-Engine, in turn, scans the data folder for presence of any pfx files and takes the first available. Another way to provide a certificate would be by using Service.Tls.Certificate proprety, where Tls property is simply resolving the TlsProvider, which you can implement yourself if you have specific needs to be addressed.

Server-Side Implementation

Our server-side implementation is very straightforward, as shown in the screenshot above we have a simple protocol that sends a secret message, and echoes the response back. This is illustrated in the figure below.

<operation name="SecretMessage"
            direction="Pull"
            suppresssecurity="true">
    <incoming>
        <member name="Name" type="String" />
        <member name="Message" type="String" />
    </incoming>
    <outgoing>
        <member name="Name" type="String" />
        <member name="Message" type="String" />
    </outgoing>
</operation>   

The only difference here is that we have the Certificate.pfx and we need to start the server listening on the port 443, which is default port for HTTPS and WSS. In this example, we also tell the server to host a couple of files for us, so we can access them via HTTPS and avoid the trouble of spinning another web server. In practice, one could use something like IIS to host the website and access the secure sockets only.

 // Just for simplicity here, and to avoid us spinning a web server, we ask Spike-Engine
// to host the files for us on HTTP protocol. That way, we can access them from the 
// browser.
Service.Http.Host("/index", "../../../MySecret.Client/index.html");
Service.Http.Host("/spike-sdk.js.src.js", "../../../MySecret.Client/spike-sdk.js.src.js");

// We also start listening to the port 443, which is default for HTTPS and WSS
Service.Listen(
        new TcpBinding(IPAddress.Any, 80),
        new TcpBinding(IPAddress.Any, 443)
        );

Client-Side Implementation

Our sample client will send continuously messages to the server through a secure websocket channel, and the server will echo the messages. The implementation is shown in the figure below.

var server, message = 0;
function sendSecret(){
    // Send a secret message
    var secret = "Secret #" + (++message);
    server.secretMessage("Bob", secret);
}

// We need to create a server on a secure port, the default port of WSS is 443, which
// we have opened on the server.
server = new ServerChannel('https://127.0.0.1');

// When the browser is connected to the server, we simply send random messages here
server.onConnect(function () {
    server.secretMessageInform = function (p) {
        var element = document.getElementById("response");
        element.innerHTML = "" + p.name +": " +p.message;
    };
    // We will send a random message 5 times per second
    setInterval(sendSecret, 200);
});

The only unusual difference is that when we create a channel, we create it on the https protocol, which tells the underlying socket.io connection to use a secure channel for websocket communication. This will issue a connect message on the wss://127.0.0.1 endpoint.

Trying it Out

Now, if we run the server, we can access the https://127.0.0.1/index resource and the browser should tell us that the certificate is not safe. That’s normal, since we’ve created a self-signed certificate just for testing purposes. Once passed that, you can examine the underlying network using F12 tools and you’ll notice that the websocket is now using the secure schema, and every packet gets encrypted/decrypted on the fly.

History

  • 10-06-14 - Initial Version

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Kel_
Chief Technology Officer Misakai Ltd.
Ireland Ireland
Roman Atachiants is the guy behind www.spike-engine.com project, a real-time, client-server networking layer (SOA, RPC) for .NET developers. Also the founder of Misakai Ltd..
 
He is a software engineer and scientist with extensive experience in different computer science domains, programming languages/principles/patterns & frameworks.
 
His main expertise consists of C# and .NET platform, game technologies, cloud, human-computer interaction, big data and artificial intelligence. He has an extensive programming knowledge and R&D expertise.

 
Follow on   Twitter

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.150301.1 | Last Updated 10 Jun 2014
Article Copyright 2014 by Kel_
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid