WebSocket transport progress

[somdoron]

• draft ZWS 2.0 rfc https://github.com/zeromq/rfc/blob/master/45/README.md
• WS address should allow path
• Send correct hostname from client to server
• use Sec-WebSocket-Protocol to negotiate protocol version and mechanism
• Validate Sec-WebSocket-Accept
• support websocket ping-pong
• support websocket close command and closing handshake
• Check validity of TLS certificates when set with setsockopt
• Support TLS with CMake
• Initiate close handshake (server only?) RFC close handshake
• Implement mechanisms in JSZMQ
• Test multipart
• Test all patterns
• document the transport
• document the WSS (TLS) transport
• support http multiline header
• Improve masking by masking 4 at a time with an integer.
• use NULL mechanism
• support zap and plain mechanism
• encoder should encode other message types, not only binary (ping/pong/close)
• Improve masking, as now it is creating a new buffer and copy it over
• Remove duplicate code from ws_connecter and ws_listener.
• TLS support
• Make ws transport conditional at build time
• Test all message sizes
• use a timer for the handshake
• Native javascript library implementing the protocol https://github.com/zeromq/jszmq

[jean-airoldie]

I have question regarding the websocket transport design.

Some websocket servers require a client to send a binary payload to subscribe to a channel or create an authenticated session. This payload is application specific and must be provided by the user. Moreover, since this payload might contain a nonce, it might change every time it is needed (so it can't be simply cached).

If restarting the websocket is done behind the curtain by zeromq (like for the other transports), there should be a way for the socket to get this user provided payload (or payloads) every time the socket is restarted. Maybe a function pointer would do the trick?

[somdoron]

My plan is to use the mechanism framework for that, initially I will support the plain mechanism which include a user and a password. Later I plan to add bearer mechanism. With mechanism each message include metadata of the sender. And you authenticate each new client using the ZAP protocol.

[jean-airoldie]

I'm not following. Authentication on websockets is kind of the wild west. Each API as its own way of authenticating. How could ZAP be adapted for these abitrary mechanism?

[somdoron]

The websocket transport is not general. It is specific to zeromq, for example the more flag is encoded as the first byte of every message. I'm working on the javascript side of it, it will be ready in few days. So only a client that will implement the ZWS protocol (which is not documented yet) will be able to communicate with zeromq on top of the websocket transport.

As part of the protocol NULL & Plain mechanism are going to be used and later bearer mechanism.

[jean-airoldie]

Gotcha, I though it was more a general purpose transport. If you also control the remote websocket it makes sense to use ZAP.

[wgaylord]

Any news?

[somdoron]

I will push to github the pure javascript library today.
At the point, you will be able to use it if you compile from source.
I believe the underlying wire protocol won't change or will have backward support, so you will be able to use it.

[somdoron]

Javascript zeromq port that can communicate with libzmq over WS transport:https://github.com/somdoron/jszmq

[somdoron]

First draft of the protocol is ready:
https://github.com/zeromq/rfc/blob/master/45/README.md

[somdoron]

WebSocket over TLS (WSS) is implemented #3695

[somdoron]

CURVE and PLAIN mechanisms now work with WS and WSS transports.
#3702

[sigiesec]

There are no tests for a websocket close command right now. Would that be feasible?

[somdoron]

There are no tests for a websocket close command right now. Would that be feasible?

Yes. The close workflow is implemented, so testing should be feasible.

[sigiesec]

There are no tests for a websocket close command right now. Would that be feasible?

Yes. The close workflow is implemented, so testing should be feasible.

I just noticed that yesterday, when I extended the test coverage job to include some more transports. I have however not seen a way to produce a close message from the libzmq code, I just found code that reacts to receiving such a message, so I wondered how that could be tested :)

[somdoron]

There are no tests for a websocket close command right now. Would that be feasible?

Yes. The close workflow is implemented, so testing should be feasible.

I just noticed that yesterday, when I extended the test coverage job to include some more transports. I have however not seen a way to produce a close message from the libzmq code, I just found code that reacts to receiving such a message, so I wondered how that could be tested :)

I guess we should implement initiation of the close handshake as well? We can do so on the unplug method and delay the termination a bit (with a timeout timer).

[somdoron]

The close handshake from the rfc:
https://tools.ietf.org/html/rfc6455#section-7

I've also added this as a checkbox item to the above list

[Elsaligi]

• Sec-WebSocket-Protocol to negotiate protocol version and mechanism

Hi, Is there any example for wss libzmq transport in python please. It will be great. I was struggle for more than 1 week for secure websocket