Client-side secure websockets (wss) would be really useful

[PaulJohnson]

Hi,

I want to interface to financial services using websockets, but obviously I don't want to do it over unsecured connections. Can I ask for client side wss support please?

This is a great library, exactly what I was looking for, until I ran into this problem.

[gertcuykens]

I think you can put a tls implementation in between like https://github.com/vincenthz/hs-tls? But I don't have a example directly. For the server side I did use for example stunnel, I guess for client side it must be trival too but I did not try it myself, so I could be wrong.

[jaspervdj]

Just a heads up -- I currently don't have time to patch this myself since my Msc. thesis has my entangled. I plan to port websockets to use io-streams after that, and that should facilitate this issue.

[markus1189]

Any updates or plans for this feature? I wanted to use websockets with a service that requires client site wss support...

[jaspervdj]

There's no utility function (yet) to do this, but there is nothing wrong with just running the connection over an SSL socket manually: https://gist.github.com/jaspervdj/7198388

[markus1189]

Thanks for the example, I got it working ;)

[mpickering]

Here's the updated code for anyone else coming across this.

https://gist.github.com/mpickering/f1b7ba3190a4bb5884f3

[leonbaum]

+1 for this. I spent a hour trying to get the "tls" package to play nicely with websockets, gave up, and finally found the OpenSSL example here.

[elfenlaid]

Here's adopted example for connection package, which is wrapper over tls.

https://gist.github.com/elfenlaid/7b5c28065e67e4cf0767

[tfausak]

:+1: Thank you for that example, @elfenlaid! I cleaned up bits of it and ended up with my own Gist. It defines a runSecureClient function that handles all the boilerplate. What would it take to get this capability into this package?

[jaspervdj]

I think a small standalone package would be more useful here, because that eliminates the need for websockets to depend on connection.

[tfausak]

I created Wuss, which exports runSecureClient and runSecureClientWith. It should be a drop-in secure replacement for Network.Websockets.

[jaspervdj]

:+1:

[Fuuzetsu]

Is there any plan to put this into websockets? I'm using wuss along with websockets which I found out in this ticket but it'd be cool to use a single blessed package which can do both.

If there's no plan, perhaps this ticket should be closed.

[nullobject]

I strongly agree wuss should be rolled into this library.

What is the benefit of keeping them separate? For users it is confusing.

[mitchellwrosen]

I'd like to cast my 2-cent vote against rolling wuss into websockets.

The tls implementation in Haskell is not awesome. It's hardly maintained, was atop the abandoned cryptonite suite which has only recently been forked to crypton (and only to perform rote dependency bump tasks - not to fully rewrite). It hasn't been audited and surely there are timing attacks due to laziness that other implementations do not have to worry about.

You can use some hardened reverse proxy like nginx to forward https:// or wss:// connections to an internal server that speaks only http:// or ws://.

As such, as a user of this library I don't want to pay the costs associated with a big dependency like tls that I will never use!

[jaspervdj]

For me, the main argument against bringing it in is the dependency footprint.

If we were to add wuss into websockets, we would likely end up splitting it again at some later date into websockets-core (this library) and websockets (wuss today).

[nullobject]

Thanks for the explanation @mitchellwrosen and @jaspervdj. It's always interesting to hear the motivations for why things are the way they are :+1:

You can use some hardened reverse proxy like nginx to forward https:// or wss:// connections to an internal server that speaks only http:// or ws://.

My use-case is a client app connecting to a third-party secure websocket, so I guess wuss is the only option for me.

If we were to add wuss into websockets, we would likely end up splitting it again at some later date into websockets-core (this library) and websockets (wuss today).

Renaming things isn't such a crazy idea. I think one of the problems is that wuss is tightly coupled to websockets, but its naming doesn't really reflect that it is essentially an extension to the websockets library.

[jaspervdj]

I would be happy to rename websockets to websockets-core and have wuss move into its place (or maybe a new websockets package that re-exports wuss). The most important thing to me in that case would be that it doesn't break existing code.

[tfausak]

If someone wants to take over wuss and rename it to something more obvious like websockets-secure, I'm on board with that.

That being said, I think maybe it would be better to add a note to the package description for websockets. There's already one in the README, but adding it to the package description would make it front-and-center on Hackage. Something like:

The websockets package only supports insecure (ws://...) websockets. If you need secure (wss://...) websockets, consider another package such as wuss.

[nullobject]

If someone wants to take over wuss and rename it to something more obvious like websockets-secure, I'm on board with that.

That being said, I think maybe it would be better to add a note to the package description for websockets. There's already one in the README, but adding it to the package description would make it front-and-center on Hackage. Something like:

The websockets package only supports insecure (ws://...) websockets. If you need secure (wss://...) websockets, consider another package such as wuss.

If there are no other takers, I'd be happy to do it.

Also a very good point re. the package description.

[jaspervdj]

I'd gladly accept a PR to update the package description, or I'll do it myself when I find the time.

[tfausak]

👉 #250