amessage: Using Jabber behind firewalls

amessage: Using Jabber behind firewalls

Artigo bom pra colocar um messenger no ar, sem mtas parafernalhas e estando dentro de uma jaula.


Using Jabber over an HTTP proxyThe more common case in which you might be interested in this document should be, that you have no administrative access to your firewall and you want to use your Jabber client behind and existing firewall. In this case this section is the best bet for you.

In this case most of the time you only have access to the world wide web and your local mail and file servers. Often users call this in my network only port 80 is open to the internet but most of the cases not even that is true because: I bet port 80 is closed as well and the users cannot connect directly to the web at all, they have to use a proxy, that relays the connections to the web. Using the proxy might be transparent and it might not be necessary to configure the proxy in your web browser, the network will then transparently route all connections on port 80 to the proxy.

There is Jabber Server jabber80.com, that allows you to connect to it using port 80. So if your network really allows you outgoing connections to this port, you might want to test this server as well. But in the case, that you have either explicitly or transparently use a transport, it won't help you that the server is listening at port 80. Proxies do not just relay your request connection to the outside web server, but will read your request, get the requested document by the outside server and forward it to you. Therefore if you send a Request to a web proxy, it has to be a valid HTTP request - and the Jabber protocol is no valid HTTP request.

The above rule that the proxy will not relay the connection but process the request itself has one important exception: HTTPS requests. The HTTPS protocol is designed to authenticate the server against the client. This is done because for some web applications (e.g. financial transactions) the user has to be sure that he is speaking to the bank and noone is able to modify the data inbetween). Therefore it cannot be accepted that the proxy is able to see or modify the request and it has only the possibility to pass the HTTPS request as it is to the server. This can be used to pass Jabber connections through the proxy very well. The only restriction a web proxy normally takes on https connections is that they have to go to the standard port for https requests which is port 443. Cause of this some Jabber servers (including all amessage servers, jabber.org.uk, jabberes.org, chrome.pl, jabber.wp.pl, jabber.elektron.com.pl and others) allow you to use port 443 to connect to them as well.

Servers urls

http://www.jabber80.com/
http://jabber.org.uk/
http://www.jabberes.org/
http://www.chrome.pl/
http://jabber.wp.pl/
http://jabber.elektron.com.pl/
amessage.info

sobre como "escapar" de um proxy eca ntlm (ms proxy)

Tunneling Out of Proxy Prison (Internet)

By Milo Minderbender
Wed May 19th, 2004 at 11:18:58 PM EST

Since I started my new job a few months ago, I've been trapped in proxy prison, unable to ssh to my home machine or any internet servers. My main goal was to use downtime at my day job to do web development work for a small company that I set up a few years ago (more on the morality of this later). I've finally broken free of the proxy prison, and here's how I did it. It wasn't easy...



--------------------------------------------------------------------------------


Rules of the Game
Damn Microsoft HTTP proxy server uses proprietary NTLM (NT Lan Manager) protocol that only MS products know how to use. This is slowly changing with Mozilla and a few other applications now able to use the protocol.
For some idiotic reason you can only leave the NTLM proxy server on the other side if you are destined for port 80 or 443. I'm not sure how Windows Media Player gets around this... I sure haven't been able to avoid it.
Solution

Luckily a similarly imprisoned python geek has written an app called aps098 that converts from normal HTTP proxy traffic to NTLM proxy traffic. Although I could have written my own NTLM authentication, my end result would have been equivalent to this program, so why bother?

I was also able to find a program called desproxy that converts normal socket traffic to HTTP proxy traffic. I saw how to do this, but I decided to just use this prebuilt app. So now I can get ssh sockets out the other end of the NTLM proxy. But then what? I still was only able leave the NTLM proxy if my destination port was 80 or 443. I had to find a way to get to the ssh port (22) on the destination server. To do this, I needed a helping hand on the other side of the NTLM proxy server.

Well, I managed to whip up a tiny web application to run on my home computer that allows me to spawn a java threaded proxy server (something I wrote a few months earlier for something else) routing from whatever local port to whatever destination server and port. So if I put in local port 443, and destination of my server, port 22, it will listen on 443 and forward whatever sockets it gets on to my server at the ssh port. This web app has to run at port 80, of course, and I can use a regular web browser to see it. After it's all set up, I just type "ssh localhost" on my machine at work, and [tada!], I get the server's login prompt!

Diagram

diagram (any admin wanna insert this image?)

Conclusion

What a bloody nightmare. Even with 4 middlemen between me and my server, the connection speed is still bordering on usable. I was able to do a full checkout of the code from CVS with no problem. Unfortunately, actually doing work would require too many switches of where the java proxy is sending me. To ssh on my home computer for scp'ing the files there, then restarting the server, then switching to my app server's port to view the application, while not being able to watch the log files (via an ssh session). It's not really gonna work. For some small self-contained problems, it could work fairly well.

On Morality and Risk

My boss and the rest of my team have specifically told me to work as slowly as possible and to always appear as if I am working. Our team has nothing to do at the moment and we actually fight over who gets to work on the bug reports as they are raised. As usual, one or two levels up the ladder, they haven't got a clue. Ahh, the corporate life: do nothing all day, get paid a lot. Own your own business: work your ass off all day and all night for pennies an hour. I'd honestly take the latter over the ladder any day.

There's absolutely no risk of getting caught. The tech services team have been around a few times to (attempt to) install upgrades and whatnot. Their incompetence was appalling! I try not to think of what they are getting paid.

Since I originally set this up, another layer of job protection has been added. The aps098 application has been moved to another unused machine using the username of an ex-employee so that other team members can run their instant messaging apps through the NTLM proxy, so the traffic is now neither coming from my ip nor using my user name.

Freedom!!!

ntlm - achei algumas coisas de ntlm estou registrando (tunneling with proxy)

http://www.kuro5hin.org/story/2004/5/19/65512/0633

http://gray-world.net/tools/
http://www.taiyo.co.jp/~gotoh/ssh/connect.html
http://desproxy.sourceforge.net
http://ntlmaps.sourceforge.net/index.html
http://www.innovation.ch/java/ntlm.html
http://devel.squid-cache.org/ntlm/
http://davenport.sourceforge.net/ntlm.html
http://jcifs.samba.org/ ***
http://www.flatmtn.com/computer/Linux-SquidNT.html#Squid-4
http://www.luigidragone.com/networking/ntlm.html