(Apologies for not writing up all the details at this moment, but I will be working more on this once I get back from Atlanta.)
The question of supporting TLS/SSL came up and since I will be implementing an OOD installation where this is a hard requirement (in addition to our exisiting installation where it’s not) I’ve been thinking of ways of making this possible. I’ve already tried @griznog’s patch for proxy.lua, which works but required defining ports beforehand and on the server side.
My idea is to instead change the function that finds a free port so that f.ex encrypted connections are on even ports, and unencrypted on odd, letting the app dev simply set a variable to instruct the port finding function.
It seems to me that this would provide the functionality required to support TLS in OOD with minimal effort, and while it’s perhaps not perfect it would be quite low effort and shouldn’t break exisisting apps.
Does this approach seem viable to the OOD dev team?
My concern would be compatibility. I think this would break existing apps if they happen to open an even port. Seems like 50/50 chance of that happening.
I created this ticket sometime ago thinking a naive implementation could set a header that the proxy could respond to.
Lots of folks really struggle to upgrade so we have to take a great deal of care in deciding when/how to break stuff. So that’s my read of this at a glance, it would break existing applications (randomly too, which would be more frustrating).
That’s the thing: the find_port function is not in the app itself, but injected by the template - so if it were to assign odd/even ports the apps would not need to change. So it shouldn’t break exisiting installations
Okay, so I’ve written a couple of patches to demonstrate my idea.
For batch_connect, the find_port function will select an odd port if USE_SSL=TRUE is set in before.sh:
For proxy.lua, the connection is upgraded if the port number is odd:
As far as I can tell, this would not impact existing installations or require app modification, as the operator would have to explicitly set “USE_SSL=TRUE” in the app scripts for this to take effect (and install/configure ssl certificates for the app, chains on the frontend and so forth) The only minor concern I can see is if a site uses an unreasonably small port range, since the number of available ports are effectively halved.
I also took the opportunity to change the failure mode from trying all ports once, to trying random ports until one is found or it times out after 1hr (which is probably overly long).