Author: JT Smith
Ries –
As you already know, AOL recently started blocking
third-party
instant messaging products from using its
network. The timing of this move happened to coincide
with a major competitor of AOL’s debuting an
AIM-compatible product, based on the
Jabber Open Source project.
Many fans of Jabber and other Open-Source AIM clones
were dismayed, and although AOL
is within its rights in blocking access to its
service, the company is making a big mistake. Many of
the
developers of Open-Source AIM alternatives have
repeatedly asked AOL to engage with them in a
constructive dialog about how their needs can be
addressed while at the same time allowing access to
the AIM
network from third-party clients.
After all, hackers are AOL customers, too.
What follows is a brief overview of the
clever technique AOL is using for its access
restrictions, and then a proposal for defeating this
scheme in a
completely legal way. This method (which is completely
generic and not tied to
AOL in particular) may provide a blueprint for
overcoming this type of blocking restriction by other
companies
in the future. Think of it as a kind of non-violent
resistance.
The AOL blocking scheme
AOL’s tactics in this case have been
well documented
elsewhere. Suffice it to say that within hours of
AOL debuting its new access restrictions, adventurous
hackers had already figured out the details and begun
the process of creating workarounds. To summarize, AOL
has
been using two methods of blocking access to its
AIM network: IP blocking and binary checksums.
Following is a description of an architecture for
defeating the second of these two methods, although it
turns out that the architecture can also be used to
defeat the first. But more on this later.
AOL has incorporated into its OSCAR protocol a
special challenge-response mechanism. When the AIM
servers receive a logon request, they send back a
special challenge. This challenge specifies a byte
range in the AIM executable (or, potentially, another
binary file
included with the AIM distribution). The client is
expected to produce the correct (unique) 16 byte
checksum for
this range of data. Because the AIM servers know which
version of the AOL software you are using (the client
is required to identify itself during logon), it can
verify if
this checksum is correct. If it is not correct, the
client is disconnected.
Easy workaround: AIM.exe
The easy workaround for this problem, and one that
many have already adopted, is the bundling of the
actual AIM windows executable. This works well,
because the
algorithm for determining the checksums on the binary
application is widely known. Of course, there are
legal problems with this, as AOL does not allow
third-parties to redistribute its binary code. A
variant on this strategy, which attempts to address
this legal problem, is allowing third-party clients to
be
configured with a “path-to-AIM” parameter. This allows
the user to download the AIM client and then tell his
third-party application where to find it. However,
because the third-party client still relies on the
actual AOL
binary for its functioning, this strategy is still of
dubious legality.
Second try: Checksum server
When this story was reported on
Slashdot,
a
widely-proposed solution was the use of so-called
“checksum servers” as circumvention devices. The idea
was that
anybody who had the AIM executable could set up a
server that would produce the required checksum to
anybody who asked. The main problem with this
approach is the load on these servers, once they were
widely known would be too high, which would prevent
them from producing the needed checksums in a timely
fashion (the AIM challenge-response times out, of
course). Further, they would be easy targets for AOL’s
lawyers, because the operators of these servers
would be violating AOL’s terms of service (by using
their binary in unacceptable ways).
Solution: Divide and conquer
The solution to this predicament is to divide the
problem into its component parts, and then solve each
of these problems separately. Further, it helps if the
solution
is generated in a distributed way. And it’s even
better if this distribution is fully anonymous, and
scalable. So
if you don’t already know about the
Freenet project,
now would be a good time to go learn.
There are actually three components involved in
sending a valid AIM logon: generating the needed
checksum, distributing this checksum to the right
client at the
right time, and sending a well-formed logon request
(including the checksum) to the AOL servers. The last
part of this problem has already been solved. The
problem we need to address is finding a way of
generating and distributing the checksum in a
completely legal way.
Solution, part one: Proxy, proxy, proxy
I propose the development of an AIM proxy server. This
server could be run by anybody, as it would be
extremely simple. All it would do is accept incoming
AIM messages, and echo these messages to the proper
AIM server. Volunteers, who used the legitimate
AOL-blessed client, would agree to modify their
LMHOSTS to instruct their computer to use the IP of
these proxies for the DNS entries that correspond to
the AIM servers.
Realize now that AOL would have no way to
distinguishing between one of these proxies and a
legitimate AIM client. If multiple people are using
the proxy at
once (which is to be expected), then AOL will not be
able to distinguish it from a legitimate NAT-based
firewall with many legitimate clients running behind
it. This is an important feature, as it makes it
difficult for AOL
to decide who should get IP-blocked.
These proxy servers would be able to (legally) watch
the traffic between their clients and the AIM servers.
In particular, they could record the checksums and
byte
ranges that are being used to pass the AOL
challenge-response. If they so chose, they could then
stick these values into their local Freenet node
cache. So far, nothing illegal is going on. Nobody has
reverse-engineered the AIM binary, checksum algorithm,
or anything. All that has happened is that certain
volunteers have agreed to publish part of their
“conversation” with AOL.
Now, some of these volunteers could decide that they
would like to run the following script, which AFAIK is
also perfectly legal. The script goes like this:
Step 1: Launch my perfectly legal AIM client
Step 2: Log into AIM (through a proxy server)
Step 3: Wait N seconds
Step 4: Terminate the AIM process
Step 5: Wait M seconds
Step 6: Repeat
Which has the effect of constantly populating the
proxy’s cache of known responses to the AOL checksum
challenge.
Now it gets better
Of course, everybody knows that this is an extremely
inefficient way to get at those values. But that’s not
so important. The important part is that it
establishes a
legal (warning: IANAL)
method for generating those checksums. Nobody is reverse-engineering
anything. Some volunteers are simply allowing others to observe and
record
parts of their conversation with AOL’s servers.
Now, when
a third-party AIM client wants to connect to AOL, they
just query their local Freenet node for the needed
checksum. When and if that checksum comes back, the
third-party client can make the reasonable assumption
that it was recorded and published by a perfectly
legal AIM proxy server.
Of course, nothing can stop somebody from performing
the following trick: create a special Freenet server
that acts a normal, serving out data from its cache,
unless it sees a request for an AIM.exe checksum. In
that case, go run the checksum algorithm on an AIM.exe
binary, and report that value. Once these values are
reported, there is no way to know whether they were
generated by such a (possibly illegal) server, or by a
legit proxy server. Further, if AOL were to discover
such a server, and shut it down, they would have no
impact on the overall functioning of the third-party
client network. Once the information is “out there” in
the Freenet network, it cannot ever be erased or
retracted.
It gets even better
To implement this system, all a Jabber server needs to
do is run a local Freenet node. Of course, many of the
values that AOL will request are not available on that
node, but if many people participate in the system,
most will be. Remember that there are something like
60,000
Jabber users, at last count. It won’t take that many
of them to keep the various Freenet caches current. As
a
special bonus, this architecture gives us a free way
to keep AOL from IP-blocking known third-party
clients:
use the proxy servers! Remember that the AIM proxy
looks completely identical to a legitimate NAT-based
firewall to AOL. So we now have a way to route
packets all around the Internet before having them
land on AOL’s doorstep. Who can they block?
Conclusions
Of course, this is just a beginning. As the free
software community takes a look at this proposal, you
will inevitably improve upon it. What I like best
about it
is that, because it uses Freenet as an underlying
transport, people are free to be part of the project
at many
different levels. New methods can be added to
supplement old. And it’s all easy to implement: Just
run a local
Freenet node alongside your Jabber/libfaim/etc.
client.
A note about AOL
I don’t mean to pick on AOL in this article, except
that it’s the first big company (that I know of)
to take the fight against open standards to this
level.
Because this system is implemented on top of Freenet,
it should be trivial to extend it to other
applications besides
AIM. The point of implementing it is not just to beat
AOL, but also to provide a real live deterrent to
other
companies contemplating the same thing. If companies
know that we can trivially and legally circumvent
their
“control” schemes, they won’t bother with them in the
first place. And that’s what open standards are all
about.
NewsForge editors read and respond to comments posted on our discussion page.
