Browsers unable to connect to SuperWebSocket when using wss ssl/tls

May 23, 2012 at 1:05 AM

I am using the latest version of the SuperWebSocket and a certificate that I created via the CertificateCreator.exe (CN=localhost).  When I try to connect via Chrome (19) or FireFox (12) Chrome locks up and Firefox simply says that it is unable to connect.

I don't have an issue if I simply use the same code without security="tls" and ws:\\ instead of wss:\\

Below is my C# code:

            var ws = new WebSocketServer();
            ws.Setup(
                new RootConfig(),
                new ServerConfig
                {
                    Name = "SecureSuperWebSocket",
                    Ip = "Any",
                    Port = 8089,
                    Mode = SocketMode.Sync,
                    Security = "tls",
                    Certificate = new SuperSocket.SocketBase.Config.CertificateConfig
                    {
                        FilePath = @"C:\AstrosLocal\SSL\localhost.pfx",
                        Password = "supersocket",
                        IsEnabled = true
                    }
                }, SocketServerFactory.Instance);


            ws.NewDataReceived += ws_NewDataReceived;
            ws.NewMessageReceived += ws_NewMessageReceived;
            ws.NewSessionConnected += ws_NewSessionConnected;
            ws.SessionClosed += ws_SessionClosed;
            ws.Start();

Below is the HTML:

<!DOCTYPE html>
    <meta charset="utf-8" />
    <title>WebSocket Test</title>
    <script language="javascript" type="text/javascript">
    <!--

        var wsUri = "wss://localhost:8089/";
        var output;
        var websocket;
        function init()
        {
            output = document.getElementById("output");
            testWebSocket();
        }
        function testWebSocket()
        {
            websocket = new WebSocket(wsUri);
            websocket.onopen = function(evt) { onOpen(evt) };
            websocket.onclose = function(evt) { onClose(evt) };
            websocket.onmessage = function(evt) { onMessage(evt) };
            websocket.onerror = function(evt) { onError(evt) };
        }
        function onOpen(evt)
        {
            writeToScreen("CONNECTED");
            doSend("WebSocket rocks");
        }
        function onClose(evt)
        {
            writeToScreen("DISCONNECTED");
        }
        function onMessage(evt)
        {
            writeToScreen('<span style="color: blue;">RESPONSE: ' + evt.data + '</span>');
            websocket.close();
        }
        function onError(evt)
        {
            writeToScreen('<span style="color: red;">ERROR:</span> ' + evt.data);
        }
        function doSend(message)
        {
            writeToScreen("SENT: " + message);
            websocket.send(message);
        }
        function writeToScreen(message)
        {
            var pre = document.createElement("p");
            pre.style.wordWrap = "break-word";
            pre.innerHTML = message;
            output.appendChild(pre);
        }
        window.addEventListener("load", init, false);  
    //!-->
    </script>
    <h2>WebSocket Test</h2>
    <div id="output"></div>
</html>

Does anyone have any suggestions?

Coordinator
May 23, 2012 at 2:14 AM

Did you check anything logged in browser's console?

May 23, 2012 at 3:32 AM

Firefox's console says: [23:31:18.339] Firefox can't establish a connection to the server at wss://localhost:8089/. @ file:///C:/AstrosLocal/SSL/ws1.htm:21,  The error event in script does get raised, but the error object is undefined.

Chrome simply hangs leaving my CPU at 100% until I stop the websocket server.  After I stop the server, the disconnect event is raised in the browser however there is nothing in the console.

Coordinator
May 23, 2012 at 3:41 AM

Could you check whether the server is running by telnet when you set the server run as wss?

May 23, 2012 at 4:02 AM

I am not sure what you are asking. The server is running under Windows XP Pro. and I am running from the console session.

May 23, 2012 at 3:53 PM

I figured out how to enable debugging to the console and here is what is happening:

(Run the program)
SecureSuperWebSocket : SubProtocol Basic found the commands below:

(Start Chrome/Firefox and  hit the page that has the javascript with the wss://)
SecureSuperWebSocket : Session: 99b06136-6f0b-42ba-a90b-4a2deef3f898/127.0.0.1:2003
New SocketSession was accepted!

(Chrome hangs here and Firefox closes the connection here)
SecureSuperWebSocket : Session: 99b06136-6f0b-42ba-a90b-4a2deef3f898/127.0.0.1:2003
This session was closed!
Closed

Any thoughts?

May 23, 2012 at 5:12 PM

I am having a similar problem.  In the SuperWebSocket solution you distribute, I set the SuperWebSocketWeb project as the default.  I then change Global.asax Application_Start method to call StartSuperWebSocketByProgramming. 

Now when I press F5, and launch Chrome to point at the localhost:2111 web site, and log in, it takes 2 minutes to get the secure web socket to connect.  The standard (ws) web socket will connect immediately.  Once the 2 minutes passes, the secure web socket connects and works correctly.  By happy coincidence, there is a 2 minute timeout for OpenHandshake and CloseHandshake timeouts.  The huge delay seems to be related to those numbers - but I don't know why.

I wrote my own server and was seeing the same problem there.  Immediate connect with standard sockets, 2 minute delay with secure sockets.  I've set up the secure sockets every which way from Tuesday (Sync, Async, etc.) but to no effect.  It takes two minutes and then works correctly.

May 23, 2012 at 5:33 PM

Additional information on the 2 minute timeout.  On the server, the SessionClosed delegate is performed after the two minute delay.  the reason is TimeOut.  Then the NewSessionConnected delegate is called, with a different session object.  It appears that there are somehow 2 sessions created, one that times out after 2 miniutes, and another that connects correctly thereafter.

May 23, 2012 at 7:43 PM

@ravi_s_desai: Thanks for the insight.  I was able to confirm your idea of two sessions.  The following is the debug info to the console:

(Starting program)
SecureSuperWebSocket : SubProtocol Basic found the commands below:

(Hitting html page with websocket from Chrome)
SecureSuperWebSocket : Session: babf57af-76d2-4114-a9e0-2403a3f2d16f/127.0.0.1:2067
New SocketSession was accepted!

(Chrome stays at 100% for about 2-3 mins)
SecureSuperWebSocket : Session: 97b96dcb-9e9f-4a03-b303-209c7a80f323/127.0.0.1:2068
New SocketSession was accepted!

SecureSuperWebSocket : Session: babf57af-76d2-4114-a9e0-2403a3f2d16f/127.0.0.1:2067
This session was closed!

ClosedSecureSuperWebSocket : Session: 97b96dcb-9e9f-4a03-b303-209c7a80f323/127.0.0.1:2068
This session was closed!
Closed

There is clearly a second session being created.

May 23, 2012 at 7:48 PM

I was able to pin point the line of code in the SyncSocketSession.cs (SuperSocket.SocketEngine) which appears to be causing the hang.

Method: SuperSocket.SocketEngine.SyncSocketSession <TAppSession, TCommandInfo>.TryGetCommand(out TCommandInfo)
Line 148:                     thisRead = m_Stream.Read(m_ReadBuffer, 0, m_ReadBuffer.Length);

The stream appears to be opened but it seems as if it is waiting on data from the browser.

Coordinator
May 23, 2012 at 7:49 PM

Is there any error log in server side?

Coordinator
May 23, 2012 at 8:08 PM

The reason is handshake failure.

Coordinator
May 23, 2012 at 8:10 PM

Could you run the Test project by NUnit? It contains test cases of secure websocket server.

May 23, 2012 at 10:42 PM

When you say server side, do you mean the PC that is running Visual Studio .NET?  If so, then I am not getting any errors from the server side.

I have never run NUnit before, however I am running VS.NET 2010.  Could you please instruct me on when I would need to do to run the teset cases?  Also, I am assuming that you are asking me to do this because you are unable to duplicate the issue?

Coordinator
May 23, 2012 at 10:50 PM

I mean the error log of SuperSocket.

May 23, 2012 at 11:10 PM

So I duplicated this same issue on my laptop at home.  I ran the test suites (using test driven .net).  They all passed: 37 passed, 0 failed, 0 skipped, took 18.54 seconds (NUnit 2.5.5).

I'm a little perplexed about the error log issue.  I'm not seeing any significant looking errors, but I may not have logging turned on the way you would like.  If I'm using the chat client example you distribute (SuperWebSocketWeb), how would I configure the error logging to see what you want?

One other thing.  Chrome is the only browser I tried that hung for 2 minutes.  Firefox and Safari just close the secure socket immediately.

 

 

May 24, 2012 at 12:19 AM

@kerryjiang: I recommend that you please try and duplicate the issue that ravi and I are experiencing.  I already provided the html code in my first post to this thread.  I really would like to use SSL and websockets with a browser (chrome, safari, firefox, etc.) and not some think client solution.

May 24, 2012 at 2:28 AM

Update: I did a test with Safari 5.1 and it has the same issue as Chrome.  I hope that this issue can be resolved.

May 25, 2012 at 2:33 PM

@kerryjiang: Is there any update on this issue?  Where you able to duplicate it from your end?

May 28, 2012 at 4:07 PM

The fine people at Google were able to the solve my problem: http://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Feature%20Status%20Owner%20Summary&groupby=&sort=&id=129748

Turns out that this wasn't an issue with the SuperWebSocket.  Instead, there was a change in both the webkit (Chrome and Safari) and gecko (Firefox) browser engines that will not allow a connection to a secure websocket for a self signed certificate unless you have accepted this certificate before hand.

So I had to create a https page on the same domain (localhost) and port (8089) and accept the SSL warning first from within Chrome.  After I did this, I was able to hit the page that contained my wss:// code from the first post and Chrome responded immediately.

Coordinator
Jun 16, 2012 at 5:12 PM

Oh, Sorry! I missed this thread.

I'll check this issue.

Nov 20, 2012 at 7:32 AM

Thanks for all the effort vbguyny, I had the same problem and it now works.

To others who might still have issues, be careful that "localhost" and "127.0.0.1" are two distinct addresses for your browser.

The certificate must be accepted on both if you want to be sure it'll work.