 |
 |
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 <[log in to unmask]> wrote: > On Jan 15, 2016, at 13:20, Salazar, Christina <[log in to unmask]> > 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 <CDN SERVICE>” in the EZproxy stanza > * Why it’s a bad idea to add “DJ <unrelated public server>” in the EZproxy > stanza > > Instead of trying to understand how proxied access works, someone just > keeps slapping “DJ <random domain>” or “HJ <random host>” 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?” > … <silence> … > Vendor: “We don’t”. > Me: “Then why do you think you need that in your proxy stanza?”. > … <silence> … > 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 <CDN SERVICE>’ to your stanza, you have > successfully negated the performance benefits of using a CDN service.”