Re: Re: Firewalls breaking stuff: [Was re: fwtk]

["Marcus J. Ranum" <mjr () ranum com>]

Charles Swiger wrote:
> Let's say a client of yours has a requirement to offer remote email access by
> employees from arbitrary Internet locations.  Would that change any of your
> comments, or would you tell the client "you can't do that?"  :-)

I don't know how many of my present/former consulting clients are
on this list but I bet there's a number who'd tell you, "oh, yes, he'd
do that..." ;)  More likely I'd say "you can't do that safely." And
then look for a compromise.

But there's a difference between how you and I appear to look for
those compromises. In every circumstance, I like to look for a
compromise approach that is as simple as possible (and no simpler)
involving the smallest number of moving parts that hook together
in the simplest possible way.
        1) It's easier
        2) It's easier to get right
        3) It's faster to get working
        4) It's easier to debug/diagnose
        5) It's easier to repair


> I'll agree that OpenSSL almost certainly has bugs.  There are some other
> alternatives, such as getting a hardware crypto-accelerator card or box, and
> using that to perform SSL.

Ah, you've fallen for the first fallacy of the appliance!!
"It's hardware" - uh, no - it's probably a PC running *BSD inside,
and it's running software - possibly OpenSSL or Bsafe (which has also
had security holes)...

SSL accelerators are _performance_ tools not security tools.
An SSL implementation is an SSL implementation; all of them will
be demonstrably more complex than leaving SSL out of the picture
at all.

- So we started with you challenging the wisdom of implementing
        only a subset of SMTP
- And I responded that that was a good thing because it let us
        leave a bunch of complexity out of the picture
- And you responded that we should get EVEN MORE COMPLEX by adding
        mystical unauditable devices to the configuration because...?
        it's better than just implementing a subset of SMTP?

> Cryptoswift is one vendor I'm familiar with in that area.
> Besides-- is there a better alternative than SSL, given the requirement above?

Well, the original question was the wisdom of implementing a
subset of SMTP on a secure gateway. I think that's still the
best option. Now, if the next question is providing secure
access to Email I'd say a VPN would work well for that,
since there's a high likelihood that the customer will have
other types of access they want to provide than just email, no?
You appear to be stuck on jamming SSL into my SMTP server.
I think you need to look at the largest scope of the problem
and come up with the smallest simplest solution to the whole
problem.

> Specification != implementation.  Or as Paul Robertson said: "A poor
> implementation, or poorly thought out implementation isn't evidence
> that a concept is or isn't flawed."

So we're violently in agreement. I think that implementing
only the parts of a specification that make sense is a wise
course when you're building mission critical software.

mjr.

---
Marcus J. Ranum                         http://www.ranum.com
Computer and Communications Security    mjr () ranum com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards