Issue #363 open
created an issue

We already have LuaSocket, so why not add support for SSL-protected networking as well?

Comments (41)

  1. Boolsheet

    The OpenSSL dependency is pretty heavy in its file size. Maybe it's possible to strip it down to just the things LuaSec needs. Then again, compiling OpenSSL has to be a very interesting adventure.

  2. Anonymous

    OpenSSL dependency is a nightmare on windows. Basically you have to run a separate installer on the client before the thing will work. It's killing a non-löve related project at my workplace.

  3. Enrique Garcia Cota


    I think the cost of adding and maintaining that dependency on all systems does not justify the benefits - the usage of SSL in games is too niche; maybe 5 or 6 people in total would need it.

    Now, if someone other than the core devs did support this on the 3 main systems, I would not have a problem.

  4. Kyle Conroy

    @Thomas R. Koll The only way is to setup an HTTP to HTTPS proxy. I'm planning on doing this via Heroku.

    +1 I would really like to be able to make HTTPS requests. I've wanted to use both the GitHub API and the Sentry API from my game, but both require HTTPS.

  5. Seppi

    I would like to have https as well. Perhaps we could just add a ./configure flag that isn't enabled by default, and distribute the binaries on the side?

    That way "normal" developers can just use the nice small binary, and win/mac developers use a love-https binary. (linux users can just make it a dependency via luarocks?)

  6. David Serrano

    I think something like luasec would be cool and is defitnally a good addition but maybe make it optional somehow. That way only the ones who use it can suffer from the extra weight.

  7. Seppi

    To put this issue in perspective, would it make sense to add libcurl to the framework, or should this workaround be documented on the wiki, and the ticket marked as wontfix?

  8. Lucien Greathouse

    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).

  9. Bart van Strien

    As I'm sure I mentioned somewhere, I do think that's the primary reason people would want TLS support, so it's definitely a solution for that, but that doesn't solve TLS in general, though. Should it?

  10. David Serrano

    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

  11. Lucien Greathouse

    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.

  12. EntranceJew

    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.

  13. Lucien Greathouse

    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.

  14. Bart van Strien

    A while back I looked at luasec (and promptly forked it to improve it), and I'd be in favour of adding that. Even if only because it's the de facto lua tls implementation.

  15. Lucien Greathouse

    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.

  16. Alex Szpakowski

    optional or add-on module to LÖVE.

    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 aren't useful for most love projects and would just add bloat in those cases, even if they're useful in some cases.

  17. Pablo Mayobre

    Well the Physics Box2D module is also unuseful for MANY projects, not sure how much of a bloat that is but still if the API comes to be it would be nice to remove the unnecessary modules entirely

    Plus would open the development of unofficial modules which would be great

  18. Pablo Mayobre

    I just realized I said something stupid since this can be done with require and a simple C/C++ library for Lua.

    Well official LÖVE modules would be great anyway. The other part never mind!

  19. EntranceJew

    If we were to be able to have, before OpenSSL (or any library being used) serves any requests it should:

    1. Send a request to a server and obtain the latest version string for OpenSSL. (One we control? The OpenSSL git repo directly?)
    2. Compare the version string.
    3. If successful, do nothing.
    4. 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.

  20. Denis Kulakov

    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...

  21. JosephG

    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.

  22. Khelz

    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.

  23. Carlo Cabanilla

    Might be a little far-fetched, but what if we generated a C shared library wrapping Go's std lib https client:

    Something like this:

    // golove.go
    package main
    import "C"
    import (
    //export Get
    func Get(url string) (status int, body *C.char) {
      resp, err := http.Get(url)
      if err != nil {
      defer resp.Body.Close()
      bodyBytes, err := ioutil.ReadAll(resp.Body)
      s := string(bodyBytes[:])
      status = resp.StatusCode
      body = C.CString(s)
    func main() {}
    // client.c
    #include <stdio.h>
    #include "golove.h"
    int main() {
        GoString url = {"", 19};
        struct Get_return resp = Get(url);
        printf("%300.300s\n\n%d\n", resp.r1, resp.r0);
    $ go build -o -buildmode=c-shared golove.go && gcc -o client client.c ./  && ./client 

    The binary is self-contained and not so big (Edit: I guess it's kind of big considering liblove is only 2.7M):

    $ ls -lah 
    -rw-r--r-- 1 carlo carlo 6.7M Jan 23 22:22

    And Go's build tools already does the hard work of compiling to every architecture (tho not until Go 1.10 for Windows)

  24. Log in to comment