[zeromq-dev] ZeroMQ WebSocket Transport: authentication
mail17 at mah.priv.at
Sat Aug 16 19:20:53 CEST 2014
Am 16.08.2014 um 18:02 schrieb Frank Hartmann <soundart at gmx.net>:
> Michael Haberler <mail17 at mah.priv.at> writes:
>> while 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
> 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
> with the bridge listening
yes so far
> on localhost.
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.
> The bridge would talk zeromq
> towards the distributed heating systems.
> I have found the following hints with respect to authentication
> 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"
> seems to be violated by your approach, if I understand things correctly?
I think this note refers to tunneling of raw TCP connections over websockets. I dont feel deterred by such opining though ;)
> On 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.
More information about the zeromq-dev