On Tue, 30 May 2000, mouss wrote:
<snip>
> actually, your approach would be interesting.. SSL designers forgot
> that there are some security concerns related to their protocol. since
> their protocol is incompatible with the security policies of many
> sites, then these sites should simply ignore this protocol.
Dont knock SSL as a transport just because it's not always the top notch
ideal thing to use along with web browsers..
It's a connection, you cant see the contents. Draw some parallels to DNS
where it's data and you (probably) dont care about scanning the contents.
Or, HTTP where you most likely cant parse/clean all the contents using the
proxy nevertheless (as discussed on this list the past few days)..
<snip>
> the same is to be said of javascript and other funny stuff.
> This is simply providing new stuff while completely ignoring the customer.
> the stuff should then go to /dev/null if there's room...
Well, if there aint room in /dev/null.... :-)
<snip>
> so what? everybody is capable of doing MD5 calculations. the problem
> is that you are faced with those millions of foreign web servers. you
And lets not forget all those miles of pipe between user and server, which
could be better traversed by data without plaintext secrets.
(I do agree that most JS implementations stink from the paranoia
perspective, however. No disagreeing there..
Nevertheless, if in bed with satan, at least make use of the central
heating..)
> can't trust them until there's a way to pursue them in case of
> problems. and that is not easy today.
True, from the perspective of reality alone, web is an evil thing..
Problem being, considering the number of bugs and malfeatures out there,
you cant really expect/rely on that the stuff you dont like stays out just
because you a) filter some of the variation in the proxy, b) disable the
thing in the browser/whatnot.
> > Dont forget that it takes just one successful hit by something that can
> > open sockets to make a nice little tunnel into your LAN, no matter how
> > many proxies or whatnot you got.
>
> how do you open a tunnel? unless you have some mean of transmitting packets
> usng some moon-based-protocol you'll have to go through the gateway, thus
> through it's filter which hands the stuff to the proxy, and if my proxy
> doesn't recognize your language, he simply won't talk to you...
Having written things tunneling stuff over http proxies (CONNECT, GET with
or without ?..., POST), NS queries (which worked rather well over just
about anything) and IDENT queries depending on connectivity, I dare say
'tis normally not that much of a problem. (Of course, if you have to
resort to sending data using If-Modified-Since: and get the replies in
the Cache*: headers, latency is a bit nasty ;-)
Considering you can tunnel anything using just -valid- requests and
replies of numerous protocols, anything that'd be able to block this in a
decent fashion would have to be devilishly smart. True, the trojan would
have to be somewhat smart as well for most of those to work, but once in,
you'll have a hell of a time trying to keep a bad one from communicating
with the outside world.
<snip>
> well, a software may be 100% secure. The real problem is whether you get
> 100% secure when using the software....
Guessingly 'no' as an answer to both of the above statements.. Heck, even
NAI is found with their pants down, where's the world heading?
> regards,
>
> mouss
ditto,
Kriss Andsten
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
