A levelez�m azt hiszi, hogy Harald Koch a k�vetkez�eket �rta:
>
> HTTP opens a security hole in a firewall, even with a proxy server. I
> have successfully run IP tunnels over HTTP through a proxy using
> off-the-shelf software. This is a red herring, IMO.
Can I beat it some more? :)
The most important advantage of flexible protocols that one can
tunnel anything through them.
The most important disadvantage of flexible protocols that one can
tunnel anything through them.
But...
If the designers of protocols would be condemned to implement a real security
proxy for their new protocols, the disadvantage could be at least in an extent
handled.
In the current state of affairs I would venture to say that a good
security proxy (firewall) should be able to stop or at least minimize
the bandwith of any known covert channel (your IP tunnel), on the protocol
it handles.
There _is_ a good security proxy for http; the one implemented in Zorp. It
can either be configured to catch your IP tunnel, or your IP tunnel is not
uses http.
The moral of the story is in the disclaimer: maybe catching the tunnel will
also stop traffic you (or your users) consider as legitimate. This is due
to the following facts:
#1: Developers barely read the specs while their implementation
works. Some say that the ones in Redmond read them, only
to make sure that their implementation differs in little
but strategic points.
#2: Developers tend to (ab)use little features of standards to
do those absolutely unnecessary bells-and-whistles.
Therefore protocol developers tend to make their
protocols in a way that the bulk of the protocol is
in that not-yet-defined-do-as-you-wish feature class.
#3: If something is (ab)used widely enough, no one will care if
it is standard or not. If you say that this something
should not be counted on, or even expressly prohibited
by the RFC, you will shortly meet some blank sights
and utter misunderstanding of your point, because someone
is already depending on it.
(I would prefer the blank blinks of blondes instead,
it alliterates better:)
It must be understood that #2 is important here. I guess most of you
(and me) regard the behaviour of the protocol developer as good
engineering practice.
_Until you start to design a proxy for the new shiny protocol._
Sorry for beating that dead red horse (or herring?) so long,
but it is an important point which is heavily underconsidered.
--
GNU GPL: csak tiszta forr�sb�l
