[OPEN-ILS-DEV] Moving TLS enforcement out of Evergreen

[Jason Boyer]

It occurred to me shortly after clicking Submit that the best place to discuss this: https://bugs.launchpad.net/evergreen/+bug/1882967 <https://bugs.launchpad.net/evergreen/+bug/1882967> would actually be this mailing list rather than LP. 

So, here it is again: 

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

Does anyone have any strong feelings about this? My inclination would be for the Evergreen backend not to even know if it’s behind TLS because you’re handling that before a request even hits us, or if it’s a localhost VM you don’t want to bother.

Jason

-- 
Jason Boyer
Senior System Administrator
Equinox Open Library Initiative
phone:  +1 (877) Open-ILS (673-6457)
email:  JBoyer at EquinoxInitiative.org
web:  https://EquinoxInitiative.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20200610/f0cbea0c/attachment.html>