Transparent HTTP proxying typically has little to no impact to user sessions in my experience.
Your strategy and what you actually intend to accomplsih seems unclear to me, though. I think the reality of how HTTP works is going to present a problem for you. Perhaps you can talk more about what you're really trying to accomplish from an end-result perspective. I'm not saying it's a "horrible idea" but it's completely unclear what you hope to gain.
From an HTTP protocol perspective your strategy has a major issue. Your layer 7 firewall can't know, by definition, the MIME type of a resource being requested until after the request is made. You can do a match on the filename (seeing it if ends in ".html", etc) but any URL can return an arbitrary MIME type. This .b0rk file is text/html
, but a match rule in your firewall on .html
or .htm
wouldn't "know" that. The request has to be made to the remote server and the remote server has to respond before the MIME type is known.
Why do you assume that other types of files (CSS, Javascript, images, etc) are "static". They certainly don't have to be. The object to which any URL refers can be "dynamic".
If you're worried about bandwidth costs why not just host a transparent proxy locally? A local proxy wouldn't incur a tenth of a second latency for requests to hit the proxy, and you wouldn't have the potential bandwidth costs associated with shipping all of your data out from a third-party datacenter. You'd also see some improvement in your local bandwidth utilization when the proxy caches objects and you could let it cache everything (that it cna).
I've run a 1,000 seat educational network through a Squid-cache instance running on hardware that, today, would seem pitiful. Unless you're talking about a very, very large network a very modest machine could handle the load for you. If you're worried about a single point of failure you could look at using Web Cache Communication Protocol (WCCP), if your edge device supports it, to do failover between a couple of caches.
If you're looking at doing this to scan HTML for "malicious" code then I think you're looking at it backwards. I'd be more worried about malicious code in Javascript and application/octet-stream
objects than about text/html
objects. I am dubious of scanning, anyway, because anything can be sufficiently obfuscated as to slip by scanning (see the Halting problem). Unless you're going to to SSL interception you're also going to miss anything delivered over HTTPS, too. Scanning can catch known exploits and I do see it as a valid part of an IT security architecture, but 0-day is nearly always going to slip right by.