[OTR-dev] Going forward

[Ralf-Philipp Weinmann]

On Dec 23, 2004, at 6:49 PM, Len Sassaman wrote:

> On Thu, 23 Dec 2004, Ralf-Philipp Weinmann wrote:
>
>> I think I'd rather prefer the AIM proxy solution with an appropriate 
>> pf
>> rdr rule (I think this is the same idea Len suggested).
>
> There's three scenarios we're looking at. The first is to use a local
> proxy on the client machine, and configure the iChat client to use that
> proxy. iChat proxy support (SOCKS5 and HTTPS) works, *except* when the
> client is on the local machine. (iChat speaks a completely different
> protocol than gaim over HTTP proxies, and we haven't looked to closely 
> at
> that.)

Hmm... This is strange. And I thought I could run iChat over my tor 
proxy, *sniff*.

>
> Due to the iChat/local proxy bug, I suggested we do a system-wide 
> network
> shim for a passive proxy instead. This has the added benefit of not
> requiring any user configuration of chat clients, and, once installed,
> will work for any chat program on the client computer.
> No luck. We were attempting to use ipfw fwd rules to direct outgoing
> traffic destined for the Oscar port to a local proxy. The traffic never
> makes it (though the rule is triggered.) I have a little more 
> debugging to
> do, but at this point I think it's pretty safe to conclude there's a 
> bug
> in the Darwin kernel with regard to this specific usage of ipfw fwd
> rules.

I have to verify that. Sorry for mixing up pf and ipfw in my previous 
message (too much OpenBSD/FreeBSD5 usage lately :)). I totally forgot 
that MacOS has ipfw and not pf.

> The final option, assuming that the above are indeed bugs that are
> unfixable outside of Apple, and won't be fixed in a timely fashion, is 
> to
> use the FreeBSD-style divert sockets (see divert (4)) supported in 
> Darwin.
> I am certain this works; however, this is considerably more difficult 
> to
> implement than the other two options, which *ought* to work anyway.
>
> Both of the ipfw-based solutions should be easily portable to other
> Unix-like OSes, so the work we'd put in on this could be useful for 
> more
> than just OS X, assuming we don't find more bugs in ipfw support on 
> other
> OSes.

I tried to go down a different route which is not really elegant (but 
neither is the ipfw hackery) but seems to works:

1) add the following line to your /etc/hosts:
    127.0.0.1       login.oscar.aol.com login.oscar.aol.com. 
login.glogin.messaging.aol.com.
2) add a new file oscarproxy to /etc/xinetd.d:
    service aol
    {
         disable         = no
         socket_type     = stream
         wait            = no
         user            = nobody
         server          = /usr/bin/nc
         server_args     = login.glogin.messaging.aol.com aol
         groups          = yes
         flags           = REUSE
    }
3) start iChat, Fire or Adium
4) replace netcat with an AIM proxy (not done yet)

 From what I have understood of the OSCAR protocol thus far, the AIM 
proxy needs to rewrite the BOS server address in the response packet 
from the authorizer after the user login. I haven't had time to whip 
together a proxy implementation yet though.

I looked into the Intego ChatBarrier thingy further. Wicked! If I do 
not misread my gdb output they have a daemon that attaches to a running 
iChat and dynamically patches it! This explains how they manage to get 
the neat little lock icons into the iChat UI... It also spells out 
trouble for compatibility with future iChat versions.

Cheers,
Ralf