WSS and WAMP

[Amichi Amar]

Hello, 

I have been using wamp to communicate between browser and server. Autobahn javascript in the browser, Autobahn python on the server. Things have been good so far. I now want to switch over to using secure websockets. 

On the server i'm doing this: 

contextFactory = ssl.DefaultOpenSSLContextFactory('keys/myapp.key', 'keys/myapp.crt')

factory = WampServerFactory("wss://myserver:80", debugWamp = debug, debugCodePaths = debug)

factory.protocol = MyAppProtocol

factory.setProtocolOptions(allowHixie76 = True)

listenWS(factory, contextFactory)    # Calls reactor.listenTCP for the factory

On the client i'm doing this: 

var wsuri = "wss://myserver:80";

ab.connect(wsuri, function(sess) { ... });

The connection between client and server occurs but then is immediately closed. Debugging I see this: 

(TLSMemoryBIOProtocol),0,76.21.0.64] WebSocketProtocol.onClose:

wasClean=False

code=1006

reason=connection was closed uncleanly (peer dropped the TCP connection without previous WebSocket closing handshake)

self.closedByMe=False

self.failedByMe=False

self.droppedByMe=False

self.wasClean=False

self.wasNotCleanReason=peer dropped the TCP connection without previous WebSocket closing handshake

self.localCloseCode=None

self.localCloseReason=None

self.remoteCloseCode=None

self.remoteCloseReason=None

Am I doing something wrong? 

How do I get WSS working with WAMP? 

Thanks!

Amichi

[Tobias Oberstein]

Am 01.11.2012 20:18, schrieb Amichi Amar:
> Hello,
>
> I have been using wamp to communicate between browser and server.
> Autobahn javascript in the browser, Autobahn python on the server.
> Things have been good so far. I now want to switch over to using secure
> websockets.

This definitely works. I.e. check out

https://webmq.tavendo.de/

All those demos use WSS.

Try opening

https://myserver:80

in your browser .. entering it into the address bar. Yes. Autobahn
should render a status page ("I am not a web server bla bla").

Probably you are using self-signed certs. You will then be prompted
to accept those .. try Firefox .. it allows to accept permanently.

Then, after accepting, try your test stuff again ..

If that does not help, please turn on logging on server: debug = True,
debugWamp = True

and report the output here ..

Cheers,
Tobias

[muehlba...@googlemail.com]

Hello together,

I'm facing the same issue. As WAMP relies upon websockets, this has to be possible, however, I get the same exception like Amichi when the client tries to connect and the server is using the WampServerFactory for Pub/sub e.g.

The output from the debug is:

2013-05-02 11:39:45+0200 [-] Log opened.
2013-05-02 11:39:45+0200 [-] myWampServerFactory (TLS) starting on 9000
2013-05-02 11:39:45+0200 [-] Starting factory <__main__.myWampServerFactory instance at 0x03575BE8>
2013-05-02 11:39:45+0200 [-] WampServerFactory starting
2013-05-02 11:39:45+0200 [-] Site (TLS) starting on 8080
2013-05-02 11:39:45+0200 [-] Starting factory <twisted.web.server.Site instance at 0x0357F738>
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] Certs are fine
2013-05-02 11:40:03+0200 [-] 127.0.0.1 - - [02/May/2013:09:40:03 +0000] "GET / HTTP/1.1" 200 1262 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:03+0200 [HTTPChannelHixie76Aware (TLSMemoryBIOProtocol),1,127.0.0.1] 127.0.0.1 - - [02/May/2013:09:40:03 +0000] "GET /index.js HTTP/1.1" 304 - "https://localhost:8080/" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
2013-05-02 11:40:12+0200 [twisted.protocols.tls.TLSMemoryBIOFactory] connection accepted from peer 127.0.0.1:56614
2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer 127.0.0.1:56614 from all topics
2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:

    wasClean=False
    code=1006
    reason=connection was closed uncleanly (peer dropped the TCP connection without previous WebSocket closing handshake)
    self.closedByMe=False
    self.failedByMe=False
    self.droppedByMe=False
    self.wasClean=False
    self.wasNotCleanReason=peer dropped the TCP connection without previous WebSocket closing handshake
    self.localCloseCode=None
    self.localCloseReason=None
    self.remoteCloseCode=None
    self.remoteCloseReason=None
   

2013-05-02 11:40:12+0200 [PubSubProtocol (TLSMemoryBIOProtocol),0,127.0.0.1] connection from 127.0.0.1:56614 lost
2013-05-02 11:40:17+0200 [-] skipping onOpenHandshakeTimeout since WebSocket connection already closed

Any advice?

Thanks!
Marc

[muehlba...@googlemail.com]

Hello there...

I figured it out!
You have also to accept the server certificate for the port the Websocket is running. I was only able to do that by entering the url with that port and doing it manually.

Now communication over wss: and https: respectively works fine.
However, I'm now facing another issue. Once I've opened the socket and closed it afterwards, I cannot reopen it again. Same for the website. After I have authenticated the client with its certificate to access the website and to allow the websocket connection, I cannot reload the page or reopen the socket. Only after deleting the browser cache, I'm able to authenticate again and open the socket. This seems to have something to do with browser ssl caching or something like that.

Any suggestions how to handle this? I want like to achieve interaction with the page and socket like without authentication, that means, the user can open and reopen the socket and reload the page as many times as he likes without re-authentication or deleting the browser cache.

Thanks!
Marc

[Tobias Oberstein]

Am 02.05.2013 13:21, schrieb muehlba...@googlemail.com:
> Hello there...
>
> I figured it out!
> You have also to accept the server certificate for the port the
> Websocket is running. I was only able to do that by entering the url
> with that port and doing it manually.

This is expected behavior for browsers, since browsers don't render
special dialogs (like "insecure certificate .. do you want to accept?")
for Web page _subresources_. Subresources are things like images, but
also WebSocket connections.

>
> Now communication over wss: and https: respectively works fine.
> However, I'm now facing another issue. Once I've opened the socket and
> closed it afterwards, I cannot reopen it again. Same for the website.
> After I have authenticated the client with its certificate to access the
> website and to allow the websocket connection, I cannot reload the page
> or reopen the socket. Only after deleting the browser cache, I'm able to
> authenticate again and open the socket. This seems to have something to
> do with browser ssl caching or something like that.

With Firefox, you can accept an invalid/insecure certificate
permantently. With Chrome - as far as I remember - you can only accept
for a browser session. Probably you can manually install your server
certificate using some settings dialog in Chrome.

Anyway. For production use, you should use a certificate signed by a CA
which certificate is built into the browser. Also important: this
certificate must include all intermediate CA certificates also. E.g. if
you use StartSSL, they have the root CA in all browsers, but the free
cert you get is signed with their intermediate cert. And the latter can
be downloaded automatically by Firefox, but not Chrome (or was it
reverse? dont remember). So include also the intermediate CA StartSSL
cert into your server cert.

Hope that helps. Getting WSS and certs right is somewhat tricky ..

Tobias

> connection accepted from peer 127.0.0.1:56614 <http://127.0.0.1:56614>

> 2013-05-02 11:40:12+0200 [PubSubProtocol
> (TLSMemoryBIOProtocol),0,127.0.0.1] unsubscribed peer

> 127.0.0.1:56614 <http://127.0.0.1:56614> from all topics

> 2013-05-02 11:40:12+0200 [PubSubProtocol
> (TLSMemoryBIOProtocol),0,127.0.0.1] WebSocketProtocol.onClose:
> wasClean=False
> code=1006
> reason=connection was closed uncleanly (peer dropped the TCP
> connection without previous WebSocket closing handshake)
> self.closedByMe=False
> self.failedByMe=False
> self.droppedByMe=False
> self.wasClean=False
> self.wasNotCleanReason=peer dropped the TCP connection without
> previous WebSocket closing handshake
> self.localCloseCode=None
> self.localCloseReason=None
> self.remoteCloseCode=None
> self.remoteCloseReason=None
>
> 2013-05-02 11:40:12+0200 [PubSubProtocol
> (TLSMemoryBIOProtocol),0,127.0.0.1] connection from 127.0.0.1:56614

> <http://127.0.0.1:56614> lost

> --
> You received this message because you are subscribed to the Google
> Groups "Autobahn" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autobahnws+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[muehlba...@googlemail.com]

Hi Tobias,

of course one should use trusted CA signed certs. I just used self-signed certs to get into the issue of client authenticatiion with certs and twisted/autobahn. But the problem persists that somehow FF relies upon a kind of cache for the cert authentication, which causes the problem that once the client is authenticated and received the page and granted access to the websocket, he cannot simply reload the page or close/re-open the socket without cleaning the cache (with IE 10 i wasn't able to reproduce this behaviouor).

Marc

[Daniel F.]

I had the issue as well.

I think accepting an untrusted cert in Firefox makes it valid for all ports. Hence, if you accept the cert on the webpage, the websocket connection will also start working. On Chrome unrusted certs will only work on the port on which the exception has been set. It also took me quite some time to figure this out, and navigate to the https of the wss port to also validate that cert.

This is where the ability of running the page and websocket on the same port should come in handy, in addition to the ease of configuring the firefall / port forwarding.

Daniel

[muehlba...@googlemail.com]

Hi Daniel,

I do run the webserver and websocket on the same port. And this seems to be a problem for the cert authentication in autobahn. Once I've accepted the cert for the page (e.g. webserver running on port 8080), the browser won't ask me again for the websocket connection. Like you said is the observed behaviour for Firefox (Chrome and IE dont make any difference here). But, the websocket connection can't be established because (I think this is the reason) the client is not asked again for authentication. And maybe this is the problem for the cert authentication procedure for autobahn/twisted. I can only circumvent this by deleting the browser ssl-cache after retrieving the page. Therefor I am asked again for authentication once I start to open the websocket. But, this is not a desirable behaviour. There must be a possibility to "save" the authentication for page AND websocket, throughout the session for example.

@Daniel: Do you have any advice regarding this?

Thanks!
Marc

[Tobias Oberstein]

Hi Marc,

Are you talking about client certificate based authentication?

Regarding "accepting invalid server cert": I have never seen the behavior you describe. And in any case, it's quite unlikely, that it's specific to Autobahn.

You can try yourself: https://webmq.tavendo.de/

Tobias

[muehlba...@googlemail.com]

Hi Tobias,

yes this is about client certificate based auth.
And yes, my guess, too, is that this has something to do with browser and caching, and not with autobahn.

Marc

[Tobias Oberstein]

Hi Marc,

ahh, ok.

I cannot say alot about client cert. based auth. with WebSocket .. only
been using Cookies and WAMP-CRA for authenticating WebSocket connections.

The arguing on the WS working group with WS auth was: we don't need a WS
auth, we can just reuse any auth mechanism that HTTP provides. This
makes some sense, but IMHO wasn't necessarily thought through to its
end. I.e. as said, WS is a _subresource_ from a browser point of view.
Which means no rendering of dialogs for "Basis HTTP Auth". Which in turn
requires the WS to run on the same host/port (origin) as the Web page
containing the JS opening the WS. And other nuisances like this ..

We need an example in AutobahnPython for that .. added an issue:

https://github.com/tavendo/AutobahnPython/issues/134

This would make it easier to test and talk about weird behaviors ..

Tobias

[muehlba...@googlemail.com]

Hi Tobias,

thanks for your troubles! I'm looking forward to see the example. And I will inform you when I figured out the weird behaviour in more detail.

Marc

[muehlba...@googlemail.com]

For all those readers who are using WAMP and webserver on the same port, here is a thread on stackoverflow in which Tobias helped me with this:

http://stackoverflow.com/questions/16234429/how-can-i-setup-an-autobahn-pub-sub-server-and-a-autobahn-webserver-listening-on

Many thanks again, Tobias!

Marc

[muehlba...@googlemail.com]

After some testing, I can say that the whole thing works in IE 10.

In Firefox and Chrome it does not work. If I first call my autobahn websocket under wss://localhost:8080/ws and authenticate with the cert, I cannot after that retrieve the page running on the webserver on https://localhost:8080. If I do it the other way round, first retrieve the page and authenticate for that, I cannot open the websocket after this.

In short: IE 10 "stores" or "accepts" one authentication for the whole session, FF and Chrome "block" or do not "store" the authentication for different ressources and hence access is denied. I also looked through the FF settings via about:config, but adjustment of ssl and caching parameters did not change anything.

Does someone else ever had these struggles when authenticating clients with certs and accessing subresources like websockets?

Marc

[Tobias Oberstein]

I guess "client cert. based auth." in the context of WebSocket is a
quite special topic not a lot people will have experience with.

One option: post your findings on

https://www.ietf.org/mailman/listinfo/hybi

This list is where WS was developed, and there are a lot WS implementors
hanging around. Including browser developers.

Tobias

[muehlba...@googlemail.com]

Hi Tobias,

has there been any progress regarding WSS and client certs?
I'm still stuck in this issue. Maybe the autobahn server does not reuse the security context of the https for the wss? Or do you think this is most likely a browser issue?

Greetings
Marc

[Tobias Oberstein]

Am 14.05.2013 12:14, schrieb muehlba...@googlemail.com:
> Hi Tobias,
>
> has there been any progress regarding WSS and client certs?
> I'm still stuck in this issue. Maybe the autobahn server does not reuse
> the security context of the https for the wss? Or do you think this is

When a browser fetches a HTML page which then opens a WS connection to a
server which serves both HTTP/HTML and WS on the same port, the browser
will nevertheless open (at least) 2 TCP connections to the server, and
the TLS will get negotiated on each TCP separately.

This isn't specific to Autobahn.

> most likely a browser issue?

Yes.

I'd expect a browser to do the following: when doing the initial fetch
of the HTML page, ask the user which client cert to authenticate with.
When subsequently fetching stuff via HTTP from or opening a WS to the
same origin, reuse the user selected client cert to (silently)
authenticate the other TCP connections as well.

You could do the following test: have a HTML page with a image element
with src empty. Have JS inside the HTML which after some delay will set
the src attribute to something on the same server. The image is a
subresource and no dialogs will be rendered, but browser should reuse
the client cert.

If that works for you with above test, but not WS, then the browser is
doing something different for WS and other subresources => bug.

If that does not work for you even for the simple img test, thats even
more severe ..

Could you do that test a report back?

Tobias

>
> Greetings

[muehlba...@googlemail.com]

Hi Tobias,

thanks for the hint. I did that small test and images get displayed as expected, without dialog and just reusing the authentication.
Hence, it seems like a browser bug. Other users on stackoverflow also stated, that this seems to be a bug in browsers and I should report it.
However, I'm really surprised that it seems that only I or just a few experienced this behaviour. If it really was a bug, there had to be more responses I guess.

I will look through the bug reports for different browsers and see if I can place my issue somewhere there.

Greetings

[Tobias Oberstein]

Hi Marc,

> thanks for the hint. I did that small test and images get displayed as
> expected, without dialog and just reusing the authentication.
> Hence, it seems like a browser bug. Other users on stackoverflow also

Interesting. Thanks for reporting back ..

> stated, that this seems to be a bug in browsers and I should report it.
> However, I'm really surprised that it seems that only I or just a few
> experienced this behaviour. If it really was a bug, there had to be more
> responses I guess.

I'd guess that using client cert. based authentication for
authenticating WS connections is not done very often.

I'd assume that most people will do cookie based auth. with WS or
implement app level auth. (e.g. as Autobahn with WAMP-CRA provides).

>
> I will look through the bug reports for different browsers and see if I
> can place my issue somewhere there.

Yep, makes sense. I'd also be interested in this .. so if you file any
bugs or find out anything relevant, could you please write a quick
notice here?

Tobias

>
> Greetings
>
> Am Dienstag, 21. Mai 2013 15:22:05 UTC+2 schrieb Tobias Oberstein:
>

> > an email to autobahnws+...@googlegroups.com <javascript:>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[muehlba...@googlemail.com]

 I filed a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=878715

[Tobias Oberstein]

I am answering again to include links so I can refer to the complete thread

http://lists.w3.org/Archives/Public/public-ietf-w3c/2011Sep/0002.html
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0583.html
http://code.google.com/p/chromium/issues/detail?id=47069
http://code.google.com/p/chromium/issues/detail?id=146848
https://bugzilla.mozilla.org/show_bug.cgi?id=878715
https://twitter.com/igrigorik/status/341439272982810624

Am 22.05.2013 13:22, schrieb muehlba...@googlemail.com:
> Hi Tobias,
>
> thanks for the hint. I did that small test and images get displayed as
> expected, without dialog and just reusing the authentication.

Yes, images and WebSocket connections are both subresources and should
be treated the same.

> Hence, it seems like a browser bug. Other users on stackoverflow also
> stated, that this seems to be a bug in browsers and I should report it.
> However, I'm really surprised that it seems that only I or just a few
> experienced this behaviour. If it really was a bug, there had to be more
> responses I guess.
>
> I will look through the bug reports for different browsers and see if I
> can place my issue somewhere there.
>
> Greetings
>
> Am Dienstag, 21. Mai 2013 15:22:05 UTC+2 schrieb Tobias Oberstein:
>

> > an email to autobahnws+...@googlegroups.com <javascript:>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[muehlba...@googlemail.com]

I finally figured it out accidentally. What did it for me, was to set a session id for the ssl context.

To do that, call this in the main of your server:
    ctx = contextFactory.getContext()
    ctx.set_verify(
         OpenSSL.SSL.VERIFY_PEER | OpenSSL.SSL.VERIFY_CLIENT_ONCE,
         verifyCallback
         )
    ## Since we have self-signed certs we have to explicitly
    ## tell the server to trust them.
    ctx.load_verify_locations("keys/ca.crt")
    ctx.set_session_id("id")

The first 8 lines are not new and needed anyway. The magic begins in line 9. Here, set a session id for the ssl context (can also be referenced elsewhere with this id),
and finally the server remembers the cert authentication also for the websocket connection.