SSL / TLS changes

[Jason Boyer]

This is a wishlist item to start some discussion around making 2 changes to Evergreen's handling of TLS.
1, given the existence of LetsEncrypt and the fact that encrypted communications aren't that large a drain on modern hardware, TLS should simply be required and assumed across the board. This could be reflected in our sample configs.

2, Enforcing #1 should also be the responsibility of apache or nginx, not OpenILS::WWW::EGCatLoader. (This is essentially the case already in many installations because redirects are so easy.) This would allow proxying to be simpler because you only need to manage certs in a single place (nginx, haproxy, whatevs) and could then use HTTP on the backend. Standing up a local test server would be significantly simpler, though Chrome's insistence on a TLS connection for localhost websocket connections is beyond our control. (Maybe more testing with FF? just requires changing wss:// to ws://...)

What do folks think?

[Bill Erickson (berick)]

+1 to both suggestions.

With Hatch using native messaging, is websockets on localhost still a concern?

[Jason Boyer (jboyer)]

It likely wouldn't be for Hatch, no, but I'm not sure if it might still cause issues with the staff client. Maybe not since I don't suppose it would necessarily be using 127.0.0.1.

[Jason Stephenson (jstephenson)]

Ditto on the +1.

[Jason Boyer (jboyer)]

This is clearly an early WIP but I do have a branch that I don't want to lose track of: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1882967_external_tls_wip / working/user/jboyer/lp1882967_external_tls_wip
It currently allow me to put nginx in front of apache and not use SSL between the two. It does *not* yet allow Evergreen to work over plain port 80 http so it's clearly incomplete but it is a start.