North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: backbone transparent proxy / connection hijacking

  • From: John Fraizer
  • Date: Mon Jun 29 19:27:07 1998

At 04:31 PM 6/26/98 -0700, you wrote:
>performance for non-HTTP protocols. Many people believe that
>large-scale caching is necessary and inevitable in order to scale
>the Internet into the future.

Horse-hockey.  Purchasing the proper amount of bandwidth from your upstream
and your upstream implementing the facilities to deliver that bandwidth is
what is necessary to scale the internet into the future.  Over-allocation
is bad enough on the dialup-ISP side of the equation without backbone
providers doing the same thing.  If your backbone provider doesn't have the
capacity to deliver what they have sole to you, it's time to contact two
entities: Your lawyer and another backbone provider.

>The Cybercash server performed client authentication based on
>the IP address of the TCP connection. Placing a proxy (transparent
>or otherwise) in between clients and that server will break
>that authentication model. The fix was to simply configure Traffic
>Server to pass Cybercash traffic onwards without any attempt to
>proxy or cache the content.

With web commerce companies popping up all over, who wants to be the one to
track these companies and their netblocks and reconfigure the proxy every
time one comes online or changes providers?  This would be a nightmare for
the dialup provider, let alone their provider or their providers provider.
If we purchase transit from provider X because provider Y doesn't peer with
provider Z from whom Commerce Provider Alpha gets their connection, who do
I yell at when my customers yell at me?  Sounds like a huge finger-pointing
match to me.  Like we don't already encounter too many of those?

>
>The second example was of a broken keepalive implementation in
>an extremely early Netscape proxy cache. The Netscape proxy
>falsely propagated some proxy-keepalive protocol pieces, even
>though it was not able to support it. The fix was to configure
>Traffic Server to not support keepalive connections from that
>client. Afterwards, there were no further problems.

See above.  Backbone providers are here to provide unhindered connection to
the internet for their clients.  If someone wants to set up a proxy, it's
their business.  Publish the address of the proxy and have at it.
Hijacking your clients, their clients, etc connections and shoving them
through a proxy cache to save money is unethical.

Transparent proxys have one place.  On the CLIENT side of the connection.

>These two problems are examples of legacy issues. IP-based
>authentication is widely known to be a weak security measure.

IP based authentication, alone, may be somewhat weaker than we would like.
It is however much more secure than having one central point on Backbone Z
that all web based traffic goes through.  IP based authentication is also
very nice augmentation for challenge/response and even simple
username/password schemes.  It limits the usefulness of authentication
tokens that fall into the hands of those who do not possess the skill-sets
necessary to do blind attacks.


>The Netscape server in question was years old. As time goes
>on, there will be a diminishing list of such anomalies to deal
>with.

This is like saying, "Internal combustion automobiles are outmoded with the
advent of plentiful gerbils to power the vehicle on treadmills."  Haven't
we all learned the backward compatibility lesson? 

>The second issue being discussed is the correctness of cached
>content. Posters have suggested mass boycotting of caching by
>content providers concerned with the freshness of their content.
>Most content providers have no such concerns, frankly. The problem
>of dealing with cached content is well understood by publishers
>since caching has been in heavy use for years. Every web browser
>has a cache in it. AOL has been caching the lion's share of

And we all know that AOL is the #1 choice of the uninitiated, a proving
ground until they graduate to a SERVICE PROVIDER vs. a Content Provider.

>US home web surfers for years. For more information on the ways
>in which publishers benefit from caching see our white paper
>on the subject of caching dynamic and advertising content:
>http://www.inktomi.com/products/traffic/tech/ads.html

"Dynamic content heuristics
               In the event a publisher has not incorporated
               cache-control headers into their site, Traffic Server
               uses a number of heuristics to recognize dynamic
               Web pages (for example, pages generated using
               cgi-bin or form submissions). These pages are
               automatically refreshed on every access."

So, If someone is using site exec, etc in their code, and their
provider/webmaster/mother didn't set up Progma: nocache, they're
effectively screwed...erm...cached, right?  


"Refresh algorithms
               For pages not utilizing cache-control headers,
               Traffic Server ships with a default refresh cycle of
               one hour for all pages. In addition, the cache uses
               sophisticated algorithms to selectively update
               rapidly changing pages at a faster rate. These
               updates are accomplished using an
               "If-Modified-Since" request, which saves bandwidth
               if the page has not changed. "

Fantastic.  So, lets say I'm Joe Banner Advertizer.  Company X has paid me
present their banner.  They wanted to limit the amount of money they spent
so, they had me code my servers to only display their banner X times per
day since I bill them on impressions.  Backbone provider Z installs one of
your boxes.  By default, no matter how many connections on the
limited....erm...client side of the box are initiated to retrieve a "fresh"
banner from our banner-farm, you send them Company X until the cache times
out.


"Users see improved performance because static
               graphics and applets are delivered from nearby
               caches, insulating them from congestion in the
               Internet cloud."


Let me rebut this quote with yet another quote from you:
"Every web browser has a cache in it."  
I'll bet on the speed of the slowest LOCAL cache against one at the
provider any day.

>And finally, there has been confusion concerning the
>confidentiality and legal issues of transparent caching.
>Transparent caching does not present any new threat to the
>confidentiality of data or usage patterns. All of these issues
>are already present in abundance in the absence of caching.

Oh really?  Lets say that I'm Joe Internet Terrorist. (Hey, they thought
that the mailman was harmless too!)  I work at backbone provider Z.  I want
to create panic on a global scale.  I insert a machine on the business end
of your proxy/cache that claims to be some corporate giant who has 80%
share of the desktop market.  Now, any requests that your cache makes are
served up by my "local" box and not the REAL webserver.  Just to make
things interesting, I tell the webserver to serve up ONE page no matter
what the request is for.  On that page, we put something to the effect of
"We have declared bankruptcy.  We will no longer support any product we
have sold you.  You're screwed."

You're saying "It would be just as easy and probably more likely that
someone would put that box at Company X instead of at the proxy/cache."

Not if they also wanted to spoof the webservers of the FBI, CIA, etc.  Now,
we have the entire internet community served by carrier Z convinced that
they're screwed.

"I couldn't resist Your Honor.  It was just too easy.  It was better than
broadcasting an alien invasion on the radio!"





-------
John Fraizer    (root)          |    __   _                 |
The System Administrator        |   / /  (_)__  __ ____  __ | The choice
mailto:[email protected]       |  / /__/ / _ \/ // /\ \/ / |  of a GNU
http://www.EnterZone.Net/       | /____/_/_//_/\_,_/ /_/\_\ | Generation
                     A 486 is a terrible thing to waste...