If we are afraid that LuaSec + OpenSSL is too big of a dependency, would using polarssl and a wrapper for that be better?
EDIT: That wrapper doesn't cover very much of the library... we would either have to write a new wrapper or just use FFI.
It's been thrown around a couple times in the IRC, but if a feature like this is going to be implemented, I feel that a libcurl wrapper might be a good route:
- Simple request model, easy to integrate
- Widespread, supported for the foreseeable future
- Can use most TLS libraries (OpenSSL, GnuTLS, whatever)
It's what luajit-request uses right now, and it works really well with support for lots of little nifty things (cookies, for example).
Can we please just add openSSL and the matching lua lib for it? That would be rather easy I would think and a larger game size is kinda OK. People expect it now. I think its a shame that we don't have SSL support
Do developers use TLS for regular game communications? I would imagine that secure game communication would retrieve a token from a login server, and then use a standard message signing method using that token, which does not rely on the integrity of the messaging protocol itself. In such a case, libcurl + a TLS library would be acceptable.
I think there's a growing need for SSL, in the very least for communications with services like Imgur, to provide a common functionality like screenshot uploading. For those unfamiliar, Imgur's API only officially supports communication via SSL and probably for good reason. Or something handy like uploading a crash log to pastebin could potentially contain personal info that they'd rather not have shared in the clear, even temporarily. Even Google is pressuring people to serve over HTTPS. luajit-request is handy, but bringing in the external dependencies of cURL is a bit of a burden and means I can't just share my HTTPS-enabled .love without having to build or roll up something for whatever platform.
GitHub and Twitter also communicate exclusively through HTTPS, which are two nice services. Additionally, any sort of game authentication should be done over HTTPS as well.
Perhaps it would be wise to include a love.https module that wraps around whatever SSL implementation the system has? It might be an undertaking, but I'm not sure what other possibilities are out there that would handle this properly.
I've done a bit of thinking on the topic and, if anything, I'm of the belief that it should be an optional or add-on module to LÖVE.
Keeping a release built against a secure enough version of OpenSSL is a large undertaking, and with the release pace expected of LÖVE it would not work well. Additionally, building OpenSSL is no fun, especially on Windows.
An add-on module would solve both of those issues I would take with the idea, which isn't far off of where LuaSec or the like are today.
Yeah. I think we'll need to figure out a general solution for that kind of thing anyway, because several things (e.g. some mobile-specific APIs like IAP or ad stuff, possibly issue #885, and maybe even love.video) aren't useful for most love projects and would just add bloat in those cases, even if they're useful in some cases.
If a conflict is detected, any calls invoking OpenSSL should return an explicit failure.
This is the most we can reasonably expect to accomplish within our realm of responsibility, and even then, a compromised version of OpenSSL probably can't be trusted to securely connect to a server.
If we wanted to make the user aware of the situation, we could show a prompt in the same way we do OpenGL incompatibilities / love version conflicts, only this one has a button to open a page on the LOVE wiki with platform-specific instructions. (If it's a release game, the wiki link can be removed with just a message that says "Sorry, certain online features may not be available due to outdated security packages.")
It sucks to say This Is The Best We Can Do but anything beyond making the user aware why stuff stopped working and letting the developer handle the exception. I don't think we can do anything else without being obtrusive / going out of line with the behaviors people have grown to expect from love.
Game developers should respond by publishing a new build of their game, the love standalone should maybe open a page of the wiki with instructions for each platform on what to do. Or have that be the default behavior and have developers override it individually.
I want to add to love2d integration with social networks - get access token from localy saved auth on mobile device, send it to my remote statistics server to easily and cheat protectly authorise user. It is possible only with https support - send auth token as open data is really bad idea. And now I am looking for solution...
Could we wrap native system libraries with a standard lua TLS frontend? As far as I know MacOS, iOS and Android all come with system-provided OpenSSL (/BoringSSL) implementations we can link against. I'd be surprised if windows doesn't ship with anything we can use.
I'd like to copy how nodejs does this, since they have the same problem as us (SSL on different platforms) and they've done a great job of providing a clean, standard API to use it. I'm not sure what they do on windows, but on other platforms they just dynamically link to the system's copy of openssl.
This issue is really blocking for us. Basically impossible to handle player authentication, leaderboards, or anything where security is a requirement, such as in pretty much any modern multiplayer games. This should be a standard feature for the engine imho.