Websocket Secure support

[BoarK]

Hi lipp,

In client*.lua I see the following code snippet:

if protocol ~= 'ws' then
error('Protocol not supported:'..protocol)
end

There is no support for wss:// ? Is secure connection support on the roadmap? A non-secured websocket connection will run into proxy problems.

Nathan.

[lipp]

Hello! wss is indeed on the roadmap. Frankly I won't start implementing this feature before ~June (Maybe someone likes to help?). It should not be too difficult employing luasec for sync/copas. The ev backends may be a bit trickier, since luasec does not seem to work non-blocking.

[rohitjoshi]

Hi @lipp,
I need to that support as well.

Thx

[lipp]

@rohitjoshi For client or server? Which backend?

[rohitjoshi]

@lipp I need support for server side.
For time being, I have switched to tornado (python) which supports wss:// but would like to use lua-websockets.

[lipp]

@rohitjoshi which backend (copas/lua-ev)? I am happy about every (happy) user, but out of curiosity: what's wrong / inconvenient with tornado / python?

[rohitjoshi]

@lipp thx. for quick reply. I used Lau-ev based lua-websockets server. Is there any advantage using one over other?
There is nothing wrong with tornado but

1. I am using openresty/luajit for my development and would like to use Lau /C where possible. C/C++ is my strength and have some experience using Lau. Eg. http://joshitech.blogspot.com/2012/09/map-reduce-implementation-in-lua.html?m=1
2. I have no experience with python so learning curve would be high.

[lipp]

@rohitjoshi Thanks, very interesting. Good choice :) I prefer the lua-ev backend, too. It is far more powerful if you want to do more elaborated IO stuff (timer, file, other sockets) etc.
Lua's easy C-Binding interface and performance are big plus! I am using it also because it has very low memory footprint and almost no (useless) dependencies. Anyhow: As stated previously I don't know, when I will tackle the secure (wss) implementation (pretty busy with other stuff I get paid for). Hopefully this will happen within the next 2-3 months. Hope this is Ok for you? Is the wss relevant for some "production" release? The API should stay the same... so maybe you could just start with the current implementation an before releasing / being serious add wss as I am ready.

[rohitjoshi]

@lipp thanks. It is not immediate product release so will use ws:// now.
I tried nginx 1.5.0 as ws:// proxy and seem to be working.
So need to try it as wss:// proxy and upstream it to ws://. If that works, may not needed.

[lipp]

@rohitjoshi nice, so no pressure for me :) BTW: good news: I just made some experiments using luasec non block (which is the crucial part) and it looks good: https://gist.github.com/lipp/5635191
Maybe it is gonna be implemented sooner than expected....

[mlschuh]

Hi lipp,

Any update on this? I looked into integrating/expanding your experiments above but am certain to break things more than fix them. My use case is client and I'll update my code to fit any of the backends (including synchronous).

-Mitch

[lipp]

@mlschuh Hello Mitch, I am very sorry, but secure websockets is still very low on prio. I will definitely not make it before end of this year.

[lipp]

as it turns out, luasec does not allow for it yet: lunarmodules/luasec#7

[mlschuh]

@lipp, No worries, I understand priorities as well as libraries not having the functionality you need. I'll look into other solutions, thanks!

-Mitch

[ckilimci]

Hi @lipp

I guess luasec ready by lunarmodules/luasec@84cb83b

Do you plan to add secure support for now? If you are or not, thank you to create such an awesome package.

[lipp]

@ckilimci thx!

just out of curiosity: what application / environment are you targeting with lua + websockets?
i guess it is something "embedded" (that's why you choose lua over e.g. node.js).

for wss servers consider this:
to employ secure websockets you need certificates, which are bound to domain names (!!!). in my environment, lua is used on embedded systems with limited ressources. unfortunately these embedded systems are not public (have no domain at all) --> using wss is pointless. you can use wss without true certs/domain pairs but this will either bother the user with warnings or will not work in future browser versions which might have tighter security policies.

for wss clients lua+websockets can make perfect sense.
i will have a look at what is a good starting point to implement wss for clients.

[ckilimci]

You are right @lipp I wanted to use lua+websocket for wss client in embedded.

[suoloordi]

Hello @lipp
Do you have any updates about this? An ETA maybe? I was looking for a ws client to use on OpenWrt and I was really glad to have found your work. It would be amazing if wss was supported.

[wranai]

Hi @lipp,

It seems luasec's ssl module can wrap tcp connections. I tried to add it to client_ev.lua. I think somethig like this should go somewhere after if connected ...:

if protocol == 'wss' then
  sock:timeout(1) -- it timed out for me without this
  sock = ssl.wrap(sock,{ mode = 'client', protocol = 'sslv23' }) -- tlsv1 segfaulted when i tried it with a plain tcp socket; may need more params, e.g. cafile = '/etc/...', verify = 'peer', options = 'all'
  sock:dohandshake() -- i don't know if it's needed for the ssl wrapper
  sock:timeout(0) -- turn async back on
end

It runs past this code fine, but it doesn't seem to work; I end up with a "closed" error from here I think, and then this happens on the cleanup():

CALLBACK FAILED: .../torch/install/share/lua/5.1/websocket/client_ev.lua:48: attempt to call method 'shutdown' (a nil value)
stack traceback:
        .../torch/install/share/lua/5.1/websocket/client_ev.lua:48: in function 'cleanup'
        .../torch/install/share/lua/5.1/websocket/client_ev.lua:64: in function 'on_error'
        .../torch/install/share/lua/5.1/websocket/client_ev.lua:82: in function 'on_err'
        .../torch/install/share/lua/5.1/websocket/ev_common.lua:38: in function 'f'
        .../torch/install/share/lua/5.1/websocket/ev_common.lua:11: in function <.../torch/install/share/lua/5.1/websocket/ev_common.lua:9>
        [C]: in function 'loop'
        ./px.lua:95: in main chunk
        [C]: in function 'dofile'
        .../torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:145: in main chunk
        [C]: at 0x00405d70

I started using lua only like a week ago, so I'm quite clueless as for what I'm missing...

[lipp]

@dakhota i highly appreciate your efforts!
hard to say what's going wrong. looks ok for me so far...maybe the overriding of sock goes wrong? is ssl.wrap really returning a sock object with tcp.socket compatible interface?

the error shown in the stacktrace definitely says: wanted to call "sock:shutdown()" but this function was not there. calling shutdown could be caused by something went wrong during previous operations or client:close() was called.

anyhow: i once started myself to do this but never finished.... some stuff was working though... maybe you want to have a look: https://github.com/lipp/lua-websockets/tree/secure-wss

[wranai]

You are right, the object that ssl.wrap returns implements only a subset of the tcp.socket interface. I tried to add a wrapper around it, one that calls the ssl method when it exists but falls back to the original socket's method when it doesn't, but it didn't work (ssl.wrap sets the socket's fd to -1, so I had to set it back to whatever it originally was.)

[Treeston]

I was looking to implement a COPAS websocket client for the Slack RTM API, which uses secure websockets (wss://), in Lua.

Disappointed to find this isn't supported.

[NovusTheory]

@lipp Disappointed to find this still isn't supported 3 years later

[lipp]

@NovusTheory @Treeston sorry for disappointing you. PRs welcome!

[NovusTheory]

@lipp #91 and everyone else

[moteus]

I write backend for lua-WebSocket based on my libuv binding (both sync and async). And it support wss wss client async example wss client sync example.

[lipp]

merged @NovusTheory PR with SSL support for sync clients. Thanks!

[dschu012]

@lipp luarocks checks out v2.2. can we get an updated tag/release with #91 ?

[venkateshveeroju]

@lipp @dschu012 @moteus @ckilimci Do we have any implementation on this request?