Frank,
Post by Frank HartmannPost by Michael Haberlerwhile designing the ZWS frame-level protocol, authentication came up
since the proxy will eventually connect to a zeromq socket, it is open
to me how this will fit in with authenticated zeroMQ sockets, and what
kind of interaction needs to be brought forward to the ZWS websocket
to cover this scenario
first guess - if we can map the woodhouse, stonehouse and ironhouse
patterns to ZWS that'd be great; strawhouse doesnt apply at the
end-to-end level but rather the proxy-to-end level and hence not part
of the ZWS protocol
for confidentiality I guess wss (websockets over TLS) is good enough,
but for authentication I think hop-by-hop isnt
any suggestions how to go forward on this?
- Michael
see also: https://github.com/zeromq/JSMQ/issues/3
Hi,
really interesting topic!
I cannot contribute much, but for a distributed home automation project
I was thinking of connecting zeromq speaking heating systems of houses
towards a central web-portal.
I was not aware of the work Doron and you are doing wrt to websockets so
I was thinking of building a C++ websocket <-> zeromq 'bridge' running on
the machine with the web-portal. Javascript would talk over websocket
with the bridge listening
yes so far
not necessarily.
Doron wants this to eventually integrate into the zeromq stack proper, so it would be remote, that'd super useful.
Just observing websockets stacks are non-trivial pieces of code, so I guess it wont happen overnight. For instance, sloccount says libwebsockets is about 8100 lines C. So I'm staying with my separate proxy process scheme until things shake out.
In my scenario I use a remote proxy for now. That could go away mostly once integration into zeromq is done; SSL encapsulation probably needs to stay outside.
My most likely scenario for websockets-to-zeromq would be like so:
- I'm looking only at actively connecting sockets from the ws client side for now, mostly sub, xsub, dealer etc
- over open networks, clients would connect with SSL (i.e. wss://)
- serving sockets would use PLAIN authentication
- during connect clients pass credentials (user/password) inband over the SSL-encrypted websocket.
- the proxy talks to the ZAP server to verify credentials, then goes ahead and does a zsocket_connect with PLAIN user/password.
That scheme works fine so far; the only downside for now is that a _remote_ connect with PLAIN authentication and invalid credentials doesnt produce a return code/error message which could be used to signal the user the connect went bad. That is possible only if the ws proxy can talk to the ZAP inproc socket, and for that it better be integrated as thread; or the credentials made available to the proxy in some other way. In private networks all this of course doesnt matter.
My current scheme allows the proxy-side socket to connect to any number of URI's, so say a SUB socket can be used to aggregate updates into a single ws connection if so desired. Same for dealer with outbound balancing. Both aggregation schemes can be done either client-side or proxy-side.
Post by Frank HartmannThe bridge would talk zeromq
towards the distributed heating systems.
I have found the following hints with respect to authentication
https://devcenter.heroku.com/articles/websocket-security#authentication-authorization
derived from this: http://lucumr.pocoo.org/2012/9/24/websockets-101/
and found this somewhat lacking and way too complex for me.
So instead of having a central web-portal for all heating systems (1:N
mapping) combined I was thinking of running a dedicated VM foreach
heating system serving that web-portal. So it will propably be more of a
1:1 mapping.
Anyway what I wanted to add: The best practice "Avoid tunneling"
https://devcenter.heroku.com/articles/websocket-security#avoid-tunneling
seems to be violated by your approach, if I understand things correctly?
Basically it is 'raw' 'zeromq' coming from javascript, isn't it?
I think this note refers to tunneling of raw TCP connections over websockets. I dont feel deterred by such opining though ;)
Post by Frank HartmannOn the other hand I have not fully understood why the situation would
improve or how I could implement "a checked and secured" higher-level
protocol if I cannot trust the data coming from the browser?
well if you do ws with SSL, you have the SSL authentication machinery for that first hop - only. That's why I was looking into authenticating the second hop too in one go.
I did the protocol provisions for client certs and server pubkeys for Curve authentication and encryption, but I'm not sure this makes much sense. It would mean the client cert has to go over the SSL pipe, or a lot more of the Curve code has to be replicated in JS. Happy about suggestions though.
- Michael