On Thu, 23 Sep 1999, Sacha Labourey wrote:
> > You mean 'packet filter' part, proxies are firewalls too.
>
> Yes you are right. I lose my latin which so many confusing technics ;)
That's ok, your English is much better than my {German, Italian, French}
:)
> I very well understand your point. But what if you wanted to developp a new
> product which needed C/S communication over the Internet? What would be the
> less "damageable" choices?
I'd probably try to use an existing protocol. New protocols are generally
difficult to get acceptance from people like me who run conservative
firewalls in large companies.
Personally, without a very compelling reason, I can't see any reason for
developing anything that doesn't use a standard Web browser these days.
The economics of client support are very compelling for a Web-based model.
> I understand it is not so much a protocol problem as an application problem
> : can you trust an application which may receive informations (i.e. commands
> maybe) from outside the innocent protected world?
Exactly.
> > Proxies must be written to handle the application protocol. A new
> > protocol won't go through a proxy solution without having an application
> > proxy written specifically for it. In firewalling terms, that's a major
> > advantage, as it keeps traffic between the somewhat-protected network and
> > the Internet restricted to a small subset of possible traffic. That
> > makes it easier to do things like trending and analysis on the traffic.
>
> but if our application only open a TCP port on a distant server, do we still
> need a specific proxy? (OK, a proxy is still needed if we want to be able to
> control the contents of the flow)
In a true "proxy" world, the proxy acts as a server for the client and a
client for the server. In other words, for instance, and HTTP proxy
answers the client as if it were a Web server, and contacts the real Web
server as if it were a Web browser.
A *lot* of people (including some vendors - one of whom initiated the
plugboard gateway) confuse a circuit-level TCP relay with a proxy.
plug-gw proxies at the transport layer, not the application layer, what
has traditionally been called a proxy works at the application layer,
hence the relatively long time to develop new functionality (good for
security, arguably bad for business.)
> > > - does it exist a standard framework to develop a proxy
> > service for a
> > > protocol which could then be used in more than one proxy product?
> >
> > Nope, proxies by definition are supposed to be application-protocol
> > aware, they should combine both the client and server edge code of the
> > application with some data-checking enforcement.
>
> OK for the client side but I meant a framework (an interface, dll, libs,
> ...) in which we could develop our specific proxy so that it can be plugged
> in different FW solutions.
No more than exist for building clients and servers. However, I'll point
out that using external DLLs and the like means you _probably_ haven't
verified the code base. For a program that exists _on_ a firewall host,
this is *very* bad.
> > ...
> > Steer clear of new protocols if you want widespread acceptance. If it's
> > compelling enough an application, stick to TCP to a single WKS port on
> > the server so it can be tunneled through something like plug-gw.
>
> sorry for my ignorance but what is a "WKS"
Well Known Service. IE Register a port with IANA and use only that port.
> > That's a lesson that's been learned the hard way with RealAudio and lots
> > of other protocols.
>
> Could you tell me a bit more about the "RealAudio lesson" learnt the hard
> way? Thank you.
The original RA client used a wide range of UDP ports. Their initial
"advice" to firewall admins was to open a very large range of UDP ports to
the Internet at large. Obviously, experienced firewallers didn't do so,
and it hurt their business-side acceptance. Next they tried a reference
proxy, which gained a little more use, but still wasn't widely accepted
other than by some firewall vendors (the more protocols a firewall lets
through, the less useful it is, since the protection mechanism is based on
blocking traffic.) Finally, they resorted to tunneling RA over HTTP, so
that rather than most sites blocking RA, most sites let it through as HTTP
traffic, and only a few sites block it. This, of course discounts the
people who think that a firewall with a "RealAudio" checkbox gives them a
significant measure of protection and click on it.
> ...
> > > P.S. : do you know some good working true transparent proxies?
> >
> > Most commercial firewalls that offer proxy protection have transparency
> > available. Not everyone will use it though - transparancy just means the
> > firewall intercepts the traffic and directs it to the proxy instead of
> > the client having to know about the proxy's address. It's a much better
> > idea to leave the option in the client, since that covers all cases.
>
> yes but it involves having the client software available for every specific
> platform.
If it isn't available, how would the user use the application in any case?
> Still a basic question for you : does client socks libraries directly relate
> to the use of proxies or not?
Socks is (or was last time I looked, which was admittedly about 2 versions
ago) a transport layer relay, I don't know how widespread its use is, but
it isn't an application layer proxy. So, SOCKS relates only to SOCKS
users, not to traditional proxy-based firewalls.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
