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