If they're worried about outgoing connections, they should setup a firewall that blocks them, too. If their firewall allows outgoing connections without having to hack around something (or crack into something), they're allowing you to create outgoing connections as a matter of policy (since NAT and IPMasq both involve very _active_ roles that the firewall must play in order to _allow_ you to create outgoing connections - clearly, a company wouldn't be so foolish as to implement an added feature only to disallow its use).
- Dave Hmm ... so much for my plan not to reply :-( Richard Dobson wrote: > > Yes but if a SOCKS server will not be setup and it is because of network > security etc then you shouldnt really be trying any method of breaching the > firewall, as that will most likely be against company network use policies > and could quite possibly get you sacked. > > Sorry to put a dampener on this it looks for for some uses (helping people > with home nats) but it has problems where it may be possibly breaching > security policies, it may also cause the network admins to actively block > all jabber connections if they find people using it to breach network > security even if they wernt too worried about it being a threat before. > > Richard > > ----- Original Message ----- > From: "Dave" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 24, 2002 2:03 AM > Subject: Re: [JDEV] DSPS > > > > Often, the problem is not technical (a SOCKS server can't be setup because > > it'd compomise network security), but is rather administrative (a SOCKS > > server can't be setup because there's too much beauracracy involved, > > plus the possibility that the network admin is too scared to poke holes > > in his firewall, not realizing that allowing outgoing connections is > > already poking a hole big enough for people to create virtual incoming > > connections). Also, an old hardware-based firewall may not even support a > > SOCKS add-on. Finally, there's no real reason for people to have to setup > > a rather complex piece of software on their firewalls just so they can > > transfer files in Jabber; let them use a server-based solution instead. > > > > - Dave > > > > BTW - Due to my bad luck at avoiding running over my quota for daily > > messages when answering your emails, I don't plan to reply to any more > > messages in this thread. > > > > > > Richard Dobson wrote: > > > > > > Why not just get people to use SOCKS5 ?? or similar instead of trying to > > > reinvent the wheel as it were. If on a corporate LAN and there is a > firewall > > > with no SOCKS server then people probably shouldnt really be trying to > > > bypass the company firewall anyway. If not then they need to pester the > > > network manager to set up a SOCKS server to service the jabber clients. > > > > > > ----- Original Message ----- > > > From: "Matthew A. Miller" <[EMAIL PROTECTED]> > > > To: "JDEV Mailing List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > > Sent: Tuesday, July 23, 2002 7:51 PM > > > Subject: Re: [JDEV] DSPS > > > > > > > > > > The original intent of DSPS was to address the problems transferring > > > > data to/from "firewalled" clients, without introducing new issues (as > > > > with PASS). > > > > > > > > The current spec talks solely about components, although a > "stand-alone" > > > > server could be utilized. Also, although it is not by design, this > > > > could handle direct connections, with one of the clients acting as a > > > > DSPS "server" (for connection-handling only; I know I wouldn't want > > > > someone trying to tell my client to create a DSPS connection for them > > > > (-: ). This (a client-side DSPS "server") is something I've thought > > > > about just recently, while looking at how we can "clean up" the > current > > > > specification. > > > > > > > > At its core, DSPS is fairly easy to support from a client (as others > > > > have stated). Also, it's "required" functionality (which, I admit, is > > > > not clearly differentiated from "optional" functionality) is not all > > > > that difficult to implement, and (with modifications, or a new spec) > > > > could be used in direct, P2P connections. > > > > > > > > Personally, I think a single "standardized" method of handling "data > > > > connections" needs to be defined for Jabber, whether it be via DSPS, > > > > PASS, or even modifications to the current OOB mechanism. Currently, > I > > > > can see DSPS as becoming an adequate, maybe even preferred, method of > > > > doing this. > > > > > > > > This is my opinion, although your mileage (and opinions) may (most > > > > likely) vary. > > > > > > > > > > > > > > > > On Tue, 2002-07-23 at 10:50, Ben Schumacher wrote: > > > > (Cross-posting, cause I think it applies to both lists.) > > > > > > > > I agree, that using a stream layer separate from the file transfer > > > would > > > > be preferred, I just think we shouldn't rely on a server as a > passthru > > > in > > > > all situations. Working around firewall issues is a problem that > has > > > been > > > > solved by nearly every peer-to-peer network in existence, so I > assume > > > > there has to be a solution that will work for Jabber. In fact, by > > > keeping > > > > the stream layer separate, it should be possible to initiate the > > > connect > > > > from either side and then do a data transfer in either direction. > This > > > way > > > > if I am behind a firewall, but the person I'm communicating with > > > isn't, I > > > > can open a connection to them and then push my data across. > Perhaps > > > the > > > > DSPS spec should be expanded/altered to the point where it doesn't > > > > necessarily imply that a proxy is necessary. > > > > > > > > Currently, the server doesn't have any knowledge of what a user's > IP > > > is > > > > beyond socket creation, and I would guess that this will stay this > way > > > in > > > > the open source implementation -- it is a privacy concern, after > all. > > > That > > > > being said, however, it would be pretty easy to write something > that > > > would > > > > have this information (a DSPS component?) available if it was > > > necessary. > > > > > > > > Does any of this make sense? I'm just trying to avoid > > > designing/developing > > > > something that will not be used, because servers probably won't > want > > > to > > > > take the extra bandwidth hit just to provide their users with the > > > ability > > > > to do file transfers. > > > > > > > > bs. > > > > > > > > On Tue, 23 Jul 2002, Justin Karneges wrote: > > > > > The problem is that there is otherwise no real clean way to > > > establish a direct > > > > > connection. Everyone is behind a firewall these days. > > > > > > > > > > Maybe jabberd should support a way of getting your external IP > > > address, so > > > > > that there could be some sort of stream negotiation between two > > > clients. As > > > > > it stands, clients don't even know what their real external > address > > > is unless > > > > > you were to specify it directly (not exactly user-friendly). > > > > > > > > > > The "stream" idea IMO makes more sense than just http URLs, > because > > > it implies > > > > > more possibilities than just file transfer. It also keeps the > > > stream > > > > > handshake as a separate layer, which simplifies things when you > > > consider the > > > > > various possible methods of transport (TCP, DSPS, PASS, > > > XML-thru-server??), > > > > > SSL, reverse-connections, etc. I completely agree with Rob > about > > > keeping the > > > > > stream layer _separate_ from the file transfer. > > > > > > > > > > DSPS is dead-easy to use from a client perspective. What we > need is > > > something > > > > > similar to it, as a standard part of jabberd, that allows > clients to > > > ask for > > > > > a stream to another JID. Something very simple like: "Oh, you > want > > > > > [EMAIL PROTECTED]/Home? Connect to this IP address." This might be > > > through DSPS, > > > > > or it might be direct, or whatever. I'm just saying, we need a > > > simple way > > > > > for clients to ask for a stream. DSPS seems to have a nice > > > interface, but it > > > > > assumes we want to route through an external point. Maybe the > real > > > solution > > > > > is to have an even smarter component that will hook you up > directly > > > to the > > > > > other person if possible, otherwise fall back to DSPS (all > hiding > > > this from > > > > > the client). > > > > > > > > > > The current situation is not optimal. > > > > > > > > > > -Justin > > > > > > > > _______________________________________________ > > > > jdev mailing list > > > > [EMAIL PROTECTED] > > > > http://mailman.jabber.org/listinfo/jdev > > > > -- > > > > > > > > Matt "Linuxwolf" Miller > > > > > > > > - Got "JABBER"? (http://www.jabbercentral.org/) > > > > > > > > _______________________________________________ > > > > jdev mailing list > > > > [EMAIL PROTECTED] > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > > > > > > > > > > > _______________________________________________ > > > jdev mailing list > > > [EMAIL PROTECTED] > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
