On 9/12/21 10:16 PM, Mehrdad Fatemi wrote:
Hi Everyone,
Hi, TL;DR: Proxy Auto Configuration
I'm looking for an elegant technology option to have telcos zero-rate all of the traffic to a set of online destinations.
I assume that "zero rating" means that specific destinations, e.g. the proxy server, are no-charge from the telco's customers point of view. If this is not what you are meaning, please correct me.
Using an SSL terminating reverse proxy could be a potential answer to this as we can focus on zero-rating the proxy's downstream traffic with each ISP/Telco without worrying about upstream servers.
I have concerns about "SSL terminating". It sounds to me like you are decidedly outside of the typical enterprise or home network scenario where you are wanting to terminate / intercept / bump-in-the-wire TLS connections. As such, I have *SERIOUS* /concerns/ about the security implications of this. -- But, I'm going to assume that you are well aware of the implications and are addressing them properly. But I'd be remiss to not say something. Moving on.
Aside: I sat on this message for a few days while messing with my own TLS bump-in-the-wire /in/ /my/ /house/ on my /home/ network. As such, I'm perfectly fine with TLS termination within environments that have the authority to do so. ;-) -- I sat on the message while working on my own Proxy Auto Configuration script to have multiple clients do what I want.
Further aside: I'm *EXTREMELY* happy with Squid's support for TLS bump-in-the-wire for my use cases; allowing ancient clients to use Squid as an encryption gateway between SSL3 / TLSv1 / TLSv1.1 and TLSv1.2 / TLSv1.3. The ability to filter various things like tracking pixels, and the caching is wonderful. -- I can't quite wrap my head around why Squid improves performance on a GPON connection, but it does. I would have thought that 1 Gbps connection would negate the need for local caching.
There are two challenges to address here though:1) Modern web applications on the upstream servers use many 3rd party and X-a-a-S resources (e.g. embedded media, libraries, etc) that we also want to pass through the proxy to ensure they are zero-rated.
That's going to be a game of Whack-a-Mole.There's also the possibility that you will proxy ~> zero-rate some common library that many other sites that don't pass through your infrastructure will use. So I suspect it's an impure WaM game at best.
2) For a user to complete an end-to-end process they may get referred to 3rd party websites (like a payment gateway) that we only want to zero-rate if the referral is from one of our designated upstream servers.
I suspect that trying to integrate conditional behavior based on account balance is going to be ... tricky, if not problematic. I'd suggest worrying about that after the fact or at a later point in the process.
Any advice on whether and how Squid and other related technologies could help is much appreciated.
I feel like a judicious use of a Proxy Auto Configuration (PAC) file / script may be a good start. It should be relatively easy for subscribers to configure their devices to utilize. Then you can update the PAC file as the WaM game requires. The PAC has the added advantage that you can direct proxy traffic to different proxy servers as necessary.
As for normal (forward) vs reverse proxy is concerned, it seems to me like your proxy will be acting as both, a reverse proxy / accelerator /and/ a /conditional/ forward proxy. The conditionality is based on the result of the PAC file's FindProxyForURL() function. You are in some ways acting as a reverse proxy / accelerator for specific sites. You are also acting as a forward proxy for clients. The behaviors just overlap in your use case. The secret sauce is in the PAC file; what does and does not get sent to your proxy.
Seeing as how you are dealing with subscribers, you probably do not want the closely related / largely overlapping Web Proxy Auto Discovery (WPAD) functionality. IMHO WPAD points to a PAC file.
-- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
