OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: HTTP in practice

Re: HTTP in practice

Greg Haverkamp (greghinstinctive.com)
Wed, 24 Sep 1997 02:43:26 -0400

Marcus J. Ranum said (11:50 PM 9/23/97 +0000):
>[...] So a firewall might
>decide to do the smart thing by zapping them [metacharacters] out of
>the URL in some manner.

Fair enough. Not a problem we face, but it's certainly a problem I can
imagine (especially given some of the way out URLs some applications are
using.)

>> > You could do something like encode your data
>> >in a "harmless" encoding that the firewall won't look into.
>
>I was thinking of encryption when I wrote the preceeding. :)
>If I were an application developer writing something that
>I didn't want people's firewalls to mess with, I think I'd make
>it encrypt its data or uuencode it or something.

Ah, yes. In a similar vain, I never saw the answer in Paul Robertson's SSL
(HTTP) Proxy thread the other day. Is anyone actually doing the MITM
approach?

I was speaking with a vendor of another product the other day who relies
upon Java applets to be downloaded. Their answer to the filtering problem
was SSL, which would equally apply to my solution. However, I just assumed
the MITM method was being used when firewall vendors speak of SSL proxies.
Further (albeit, cursory) investigation led me to the opposite conclusion.

However, if most don't handle that, and assuming that most firewall
administrators can't get away with not allowing https access to the outside
(which seems a fair assumption to me), all of these issues become somewhat
moot. Executable content can then only be controlled via control of the
desktop. And that's pretty damn elusive.

>[Using app-specific MIME-type]
>It means, however, that (unless your mystery app is very
>cool and useful, and wotnot) someone will be ordered
>by management to screen that mime type at the firewall.

Well, that's the trick, isn't it? I've even been forced to make
concessions for those things that are not even necessarily cool or useful.
And that's disturbing (from the firewall administration perspective.)

I find myself continually pushing back to the political realms of all of
this. We have to make the right people want the product. Compounding our
problems are even diagnosing just what the issue is. I'll complain about
administrators elsewhere, but I can just imagine my response to someone
from some other software company calling me up and asking me to tell them
about my firewall settings.

[As a quick note: I didn't mention much about the application, eRoom,
mainly because I was trying to avoid specifics, and it wasn't my goal to
evangelize on this list. I'm trying to avoid saying more than I'm allowed.
 With a sniffer you can get more information than I've given. But here's a
URL for the curious: http://www.instinctive.com/product/productbrief.htm ]

>There's a subtle (and pernicious) security implication hidden
>in things like ICQ: all the users are on Windows. If you're a Bad Guy
>and you're going after someone on ICQ you can be about 90%
>certain their on W95. 8% certain it's NT. Solves a lot of the
>portability problems in writing attack applets. I'm starting to get
>crazy in my old age and am increasingly afraid that the Windows
>juggernaut is going to kill us through lack of biodiversity against
>future bugs and worms.

Write once, run anywhere... Hadn't given it much thought previously, but
it's true. It might not long before some pretty similar code, compiled
twice (once for CE and once for 95/NT/NT Alpha FX!32) could take out your
handheld scheduler, your workstation, your server, and your TV! Well, if
CE ever gets enough of the key components of the Win32 API.

Greg 

---
Greg Haverkamp, Network Administrator/Webmaster, Instinctive Technology 
See eRoom at http://www.instinctive.com "Where Teams Get Down to Business"
Of my many opinions, consider only one to be that of my employer:
I drink far too much Diet Coke

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:08:58 CDT