In some email I received from Marcus J. Ranum, sie wrote: > > > >The only context I can think of this making any sense is when you > >have an inside agent program that makes an SSL connection to an > >external host for the express purpose of providing access to systems > >on the inside (sort of like dial-back). > > You mean like if someone made a back orifice plug in or > something like that? Hmmm. Not sure. Let me explain. If I somehow get an internal box with an agent installed which makes connections outbound on port 80 and only does so in response to a magic email message that I send, then it is highly likely a proxy will dump it if it's not HTTP. Then again, if the end is effectly an in.rshd, compiled with SSL, and *connects* to my rsh process that listens on port 443 (again in response to a magic email), then no magic proxy can determine if it's HTTP or anything else. In the second case, the only way you *might* determine it's not HTTP is through packet analysis - HTTP doesn't send lots of short packets in both directions, in measurable levels of spurtiness. > >The `solutions' are not pretty: disable any protocol using encryption > >because the firewall cannot validate the message's integrity or force > >everything to be decrypted and re-encrypted as required to allow the > >message to be checked that it matches the right protocol. > > > No, it's worse. The 'solution' is to disable any protocol > that issues connections which are not immediately tied to > an authentication that isn't performed by a computer. Is that sufficient ? Users are pretty dumb, after all. Darren
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:00:16 PDT