On 10 May 2001, Michael T. Babcock wrote:
> On 10 May 2001 10:26:13 -0400, Paul D. Robertson wrote:
> > 1. "Among others" is one of the telling phrases. Not that any streaming
> > protocol is particularly security freindly, including 323.
>
> And what evidence do you have that any streaming protocol is a security
> risk, since you harp on them?
The same evidence that makes HTTP a security risk with tunneling- lack of
ability to control what gets passed and detect and stop things which abuse
the channel. Added to the fact that the protocols are based on
throughput, and therefore designed to be passed quickly, not inspected.
> > 2. Streaming media protocols aren't "proxied", they're passed.
>
> Oh? Would you mind reading up on how H323 gatewaying works and come
> back later?
Oh, would you mind contacting a dozen firewall vendors and finding out how
much inspection of the content goes on? Unless the state of the universe
has changed since I did my last evaluation, the number of bytes tested by
most deployed products prior to passing the UDP stream from hell[tm] is
less than 100.
> > going to be a signficant tunneling vector outside of HTTP and DNS, H.323
> > will be the one.
>
> And how do you propose that anything be proxied over H323?
The same way it's done via HTTP or DNS, but with the larger ammount of
data required by streaming media, detection will be more difficult than it
is with DNS and potentially HTTP.
> > 4. Firewalls protect based on *blocking* traffic, not on passing it.
>
> Yes, by setting DENY all data on my machine, I'm much happier. I can't
> send or receive E-mail or browse the web. The point of being connected
> to the Internet is to enjoy its functionality _while_ remaining
> sufficiently secure. Security is not the end-all and be-all of every
> company's existance.
However, security IS the job of the people who read this list. A
significant number of administrators need to understand that the check box
that says "H.323" doesn't mean the firewall is providing significant
security value.
> > > Interoperability is important because if you're
> > relying on either proxy enforcement or protocol specifications for any
> > measure of prortection, then deviations change the evaluation.
>
> I use OpenH323 software for Linux to talk to people on Netmeeting. It
> works. That's my evidence. If you don't know anything about the
> protocols or software in question, why do you bother commenting?
I look at more than one implementation when measuring interoperability,
and I've specificly given the timeframe that I was looking in detail at
the protocol and product.
> > Can I encrypt a video or audio call?
> >
> > No. When you use encryption you are forced into a "data only" mode.
> > Audio and video are disabled.
>
> That would assume that you don't set up VPNs between your network and
> the networks you want to conference with, then send your data over those
> channels. If your data isn't confidential and you want something as
> private and secure as E-mail (which isn't either), then Netmeeting fits
> the bill, even broadcast over the Internet.
Most people don't even *know* that they need ancillary encryption because
the marketing collarteral doesn't contain exceptions.
>
> > Whoops! So much for completelness of implementation for security, so
> > much for confidentiality of information passed over the 'Net...
>
> You use E-mail, right? Do you PGP encrypt everything you send to
> associates?
>
> > Doesn't sound all that standard to me, and the phrase "stil requires som
> > eports to be opened" should be a red flag.
>
> Why? If it didn't require ports to be opened, it either wouldn't be a
> standard internet protocol (which use IP ports) or it would be tunneling
> over some other less-secure protocol (like HTTP, God-forbid).
Because the range of ports is obviously not covered by the "standard
H.323 application." So much for the standards argument.
> You don't even know what the software does, so you diagnose it as a
> chest wound?
Just because you don't agree with the perspective doesn't mean I haven't
evaluated the application. Your idea of risk management is obviously
significantly different than mine. I've never been a fan of "open wide
and swallow."
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
