Websockets: No way to set server certification for SSL

[czyzby]

Websockets: No way to set server certification for SSL

[czyzby]

My web sockets library is basically a wrapper around other libraries (or "native" websockets in case of GWT). I think you should investigate nv-websockets first.

[hollowbit]

I looked into it quite a bit and I will make a commit request in a bit once I have the chance to write up the code. So far I only have the solution for CommonWebsockets, using nv-websockets like you recommended.

Basically, the solution is simple, since nv-websockets has strong SSL support. The only thing that is required is to create a new connect() method for com.github.czyzby.websocket.impl.NvWebSocket and AbstractWebSocket allowing to pass a store type, keystore location, key password & and store password. If you want more details to what the code looks like, I have actually done this before, here (In the constructor of this class).

Then all that is needed to do is use the com.neovisionaries.ws.client.WebSocketFactory's setSSLContext(SSLContext context) method to set the ssl context before connecting and NvWebSockets should handle the rest.

Do you think that this solution is good?

[czyzby]

Pull requests are always welcome. I'd have to look into your code, but the solution seems fine. You could add some generic SSL data object to the web socket interface and handle it accordingly for each concrete web socket implementation. The thing is - setting it up on GWT might be very problematic and require drastically different approach.

[hollowbit]

I got it working on android now. It was a bit more complicated since android uses "BKS" keystores as opposed to the Java standard "JKS" keystore (probably for legal reasons). I'm trying to find a developer friendly approach to let the library's users know to use bks for android and jks for desktop (and most likely iOS).

I have no way of testing on iOS but I think it should work. I just have to find a solution for GWT. It may take some more time, especially since I am busy with school now. So far it is fairly unattractive but I will make it nice and clean and eventually make a pull request.

[czyzby]

Looking forward to it.

[hollowbit]

Would you have any ideas on how to add SSL support for GWT? I haven't been able to get anywhere with it, besides adding the {rejectUnauthorized: false} argument when creating a WebSocket, which didn't work.

[czyzby]

Not sure if you can just define your custom keystore in a browser. It would be a questionable design choice if any JavaScript code could just swap website certificates at runtime. When connect with a HTTPS handshake, your browser finds out if website certificate is valid and can be trusted. Then you can only use wss to connect with the server and the connection is already considered safe.

[hollowbit]

So the website hosting the Libgdx game/app must use HTTPS? Does this mean that WSS cannot be used with basic HTTP? If that's the case then I guess I will have to drop GWT support for my game, at least until I get a proper certificate. But even then, how do I debug my game using a localhost server?

[czyzby]

Let's Encrypt. You can ignore a huge warning about a self-signed certificate and still use HTTPS for your local server to debug encrypted WS connection. I wouldn't bother though and just work on regular web sockets during development.

Still - chances are your users will not be so forgiving when seeing an invalid certificate warning, so you better get a proper one for your production server.

[hollowbit]

That makes sense. I will look into that and let you know. Thanks.

[czyzby]

@vedi0boy Any updates on this?

[hollowbit]

I wasn't able to find a way to support it for GWT so I figured there was no point in submitting the code for the other versions.

[czyzby]

That's because the browser handles certificates, it's not your job to do so. I think it would be fine to just log some message on GWT backend ("Custom certificate is not supported on GWT."), and it wouldn't be the first time to be honest. As long as you can abstract Java and Android implementations to a single interface, possibly consuming the same file types, I'm willing to accept any related pull requests. If you don't think it's worth the effort, I'll close the issue.

[hollowbit]

I am not completely confident with my current solution. It works but there may be some security flaws. I think you should just close the issue and if I ever find a good solution, I will be sure to make a pull request.

[czyzby]

OK, thanks for your efforts.