 |
 |
One of the reasons that EZProxy is so fast and resource-efficient is that it is very lightweight. HTTPS to HTTP processing would require that EZProzy, or another proxy layer behind it, provide an HTTPS endpoint. Building this into EZProxy, I think, would not be a good fit for their model. I think that it would be simpler to just do everything in nginx, or possibly node. Cary On Wednesday, June 18, 2014, Andrew Anderson <[log in to unmask]> wrote: > On Jun 17, 2014, at 17:09, Stuart Yeates <[log in to unmask] > <javascript:;>> wrote: > > > On 06/17/2014 08:49 AM, Galen Charlton wrote: > >> On Sun, Jun 15, 2014 at 4:03 PM, Stuart Yeates <[log in to unmask] > <javascript:;>> wrote: > >>> As I read it, 'Freedom to Read' means that we have to take active > steps to > >>> protect that rights of our readers to read what they want and in > private. > >> [snip] > >>> * building HTTPS Everywhere-like functionality into LMSs (such > functionality > >>> may already exist, I'm not sure) > >> > >> Many ILSs can be configured to require SSL to access their public > >> interfaces, and I think it would be worthwhile to encourage that as a > >> default expectation for discovery interfaces. > >> > >> However, I think that's only part of the picture for ILSs. Other > >> parts would include: > >> > >> * staff training on handling patron and circulation data > >> * ensuring that the ILS has the ability to control (and let users > >> control) how much circulation and search history data gets retained > >> * ensuring that the ILS backup policy strikes the correct balance > >> between having enough for disaster recovery while not keeping > >> individually identifiable circ history forever > >> * ensuring that contracts with ILS hosting providers and services that > >> access patron data from the ILS have appropriate language concerning > >> data retention and notification of subpoenas. > > > > Compared to other contributors to this thread, I appear to be (a) less > worried about state actors than our commercial partners and (b) keener to > see relatively straight forward technical fixes that just work 'for free' > across large classes of library systems. Things like: > > > > * An ILS module that pulls the HTTPS Everywhere ruleset from > https://gitweb.torproject.org/https-everywhere.git/tree/HEAD:/src/chrome/content/rules > and applies those rules as a standard data-cleanup step on all imported > data (MARC, etc). > > > > * A plugin to the CMS that drives the library's websites / blogs / > whatever and uses the same rulesets to default all links to HTTPS. > > > > * An EzProxy plugin (or howto) on silently redirectly users to HTTPS > over HTTP sites. > > > > cheers > > stuart > > This is something that I have been interested in as well, and I have been > asking our content providers when they will make their content available > via HTTPS, but so far with very little uptake. Perhaps if enough customers > start asking, it will get enough exposure internally to drive adoption of > HTTPS for the content side. > > I looked into what EZproxy offers for the user side, and that product does > not currently have the ability to do HTTPS to HTTP proxying, even though > there is no technical reason why it could not be done (look at how many > HTTPS sites run Apache in a reverse proxy to HTTP servers internally for > load balancing, etc.) > > EZproxy makes the assumption that a HTTP resource will always be accessed > over HTTP, and you cannot configure a HTTPS entry point to HTTP services to > at least secure the side of the communication channel that is going to > contain more identifiable information about the user, before it becomes > aggregated into the general proxy stream. > > -- > Andrew Anderson, Director of Development, Library and Information > Resources Network, Inc. > http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | > http://www.facebook.com/LIRNnotes > -- Cary Gordon The Cherry Hill Company http://chillco.com