Re: [CODE4LIB] [patronprivacy] Let's Encrypt and EZProxy

2016-01-16 Thread Andrew Anderson
On Jan 15, 2016, at 13:20, Salazar, Christina  
wrote:

> Something that I also see implied here is why aren’t vendors doing a better 
> job collaborating with the developers of EZProxy, instead of only putting the 
> pressure on Let’s Encrypt to support wildcard certs (although I kind of think 
> that’s the better way to go).


Because it’s easier than actually taking the time to fully understand the 
platforms and how all the pieces fit together.  

I’ve lost track of how many discussions I have had with various vendors 
recently over:

* Why they need to encode URLs before trying to pass them to another service 
like EZproxy's login handler
* Why they really do need to pay attention to what RFC 2616 Section 3.2.2 and 
RFC 2396 Section 2.2 have to say regarding the use of the reserved character in 
URLs
* Why it’s a bad idea to add “DJ google.com” in the EZproxy stanza
* Why it’s a bad idea to add “DJ ” in the EZproxy stanza
* Why it’s a bad idea to add “DJ ” in the EZproxy 
stanza

Instead of trying to understand how proxied access works, someone just keeps 
slapping “DJ ” or “HJ ” into the service stanza 
until the service starts working, and then never revisits the final product to 
see if those additions were really necessary.  Do this for a few platform 
iterations, and the resulting stanza can become insane.

The conversations typically go something like this:

Me: “Why are you trying to proxy google.com services?” 
Vendor: “Because we’re loading the jQuery JavaScript library from their CDN."
Me: “And how are you handling registering all your customer’s IP addresses with 
Google?” 
…  … 
Vendor: “We don’t”.
Me: “Then why do you think you need that in your proxy stanza?”. 
…  …
Vendor: “We . . . don’t?”
Me: “Exactly. And how are you reaping the performance benefits of a CDN service 
if you’re funneling all of the unauthenticated web traffic through a proxy 
server instead of allowing the CDN to do what it does best and keeping the 
proxy server out of the middle of that transaction?"
Vendor: “We . . . aren’t?”
Me: “That’s right, by adding ‘DJ ’ to your stanza, you have 
successfully negated the performance benefits of using a CDN service.”

-- 
Andrew Anderson, President & CEO, Library and Information Resources Network, 
Inc.
http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | 
http://www.facebook.com/LIRNnotes


Re: [CODE4LIB] [patronprivacy] Let's Encrypt and EZProxy

2016-01-16 Thread Chris Moschini
Andrew, great analysis.

So, letsencrypt and EFF have an obvious goal here, and these vendors are in
the way. There's a noble purpose here, so what can we do to move vendors
towards it? Perhaps if there was a Kickstarter for someone or a team to:

1) Determine the top vendors in this space, by usage.
2) Pick say the top 50 and analyze exactly what if anything they're doing
that gets in the way, for example these DJ stanzas.
3) Name and Shame.

That would hopefully be enough to move the majority of those vendors
towards patches. Possibly a consulting approach for those that don't move.

Think that'd help? Think it'd have traction?



On Sat, Jan 16, 2016 at 3:25 AM, Andrew Anderson  wrote:

> On Jan 15, 2016, at 13:20, Salazar, Christina 
> wrote:
>
> > Something that I also see implied here is why aren’t vendors doing a
> better job collaborating with the developers of EZProxy, instead of only
> putting the pressure on Let’s Encrypt to support wildcard certs (although I
> kind of think that’s the better way to go).
>
>
> Because it’s easier than actually taking the time to fully understand the
> platforms and how all the pieces fit together.
>
> I’ve lost track of how many discussions I have had with various vendors
> recently over:
>
> * Why they need to encode URLs before trying to pass them to another
> service like EZproxy's login handler
> * Why they really do need to pay attention to what RFC 2616 Section 3.2.2
> and RFC 2396 Section 2.2 have to say regarding the use of the reserved
> character in URLs
> * Why it’s a bad idea to add “DJ google.com” in the EZproxy stanza
> * Why it’s a bad idea to add “DJ ” in the EZproxy stanza
> * Why it’s a bad idea to add “DJ ” in the EZproxy
> stanza
>
> Instead of trying to understand how proxied access works, someone just
> keeps slapping “DJ ” or “HJ ” into the service
> stanza until the service starts working, and then never revisits the final
> product to see if those additions were really necessary.  Do this for a few
> platform iterations, and the resulting stanza can become insane.
>
> The conversations typically go something like this:
>
> Me: “Why are you trying to proxy google.com services?”
> Vendor: “Because we’re loading the jQuery JavaScript library from their
> CDN."
> Me: “And how are you handling registering all your customer’s IP addresses
> with Google?”
> …  …
> Vendor: “We don’t”.
> Me: “Then why do you think you need that in your proxy stanza?”.
> …  …
> Vendor: “We . . . don’t?”
> Me: “Exactly. And how are you reaping the performance benefits of a CDN
> service if you’re funneling all of the unauthenticated web traffic through
> a proxy server instead of allowing the CDN to do what it does best and
> keeping the proxy server out of the middle of that transaction?"
> Vendor: “We . . . aren’t?”
> Me: “That’s right, by adding ‘DJ ’ to your stanza, you have
> successfully negated the performance benefits of using a CDN service.”