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

["Charles Swiger" <chuck () codefab com>]

On Friday, July 19, 2002, at 04:47  PM, Paul Robertson wrote:
> On Fri, 19 Jul 2002, Charles W. Swiger wrote:
[ ... ]
> > Nor should you.  Please explain why SMTP AUTH or performing SSL-based
> > encryption of mail en transit via STARTTLS is "stupid" rather than
> > important functionality which improves security?
>
> It's stupid when requirements specifiy things which make those things bad
> (like in brokerages where public wires must be monitored and the
> monitoring mechanism may be transit based. - That doesn't mean you can't
> architect around it, but it does show that "security" features aren't
> always "right"-- if the SEC shuts you down, your security funtionality
> just cost you the business.)

You're positing a situation equivalent to a legal requirement to monitor 
HTTPS traffic en route, which is hardly a common situation.  STARTTLS or 
SMTP AUTH are features which are not enabled by default under most MTAs;
if there was a reason not to use them, don't turn them on.

For that matter, you could decode STARTTLS traffic if you have legitimate 
access to the mail server's private keys and thus the monitor can follow the
SSL session, in much the same way that one could monitor HTTPS traffic.

> > If you also provide SSL-based IMAP (993/tcp), you can provide email 
> > access for remote employees where their usernames, passwords, and the mail 
> > itself is never sent in plain text.  That seems quite worthwhile to me.
>
> Encryption isn't a magic bullet- suddenly you're providing remote access
> to potentially sensative data possibly with weak authentication.

Encryption isn't a magic bullet.  If you can not exchange mail with the
outside world at all, of course you don't run an MTA, any more than you
would run any other service that wasn't necessary.

However, I'm not "suddenly" providing remote access; the requirement for 
employees to be able to remotely access email is quite a bit more common 
at most organizations than the reverse.  Given that as a functional 
requirement for a "working" network, I'd prefer to provide these services 
in a way that's more secure rather than less secure.

> Sometimes it's worth the risk, but just because it's encrypted doesn't
> mean it's good.  Encrypting something you're already doing may provide
> better security, providing something *because it's encrypted* mostly
> doesn't.

For people that use reusable passwords rather than S/Key or other one-time 
password systems, are you claiming that SSL-based encryption is less 
secure than plain text?

Would plain text be better under any circumstances?  (If so, why?)

> > Someone capable of implementing SMTP correctly is more likely to produce
> > secure code than someone not capable of implementing SMTP correctly.
>
> I'm not sure this follows- people who focus on implementing SMTP correctly
> aren't always the same as people who focus on implementing SMTP securely.

Writing something that does basic SMTP is very easy; writing SMTP (or 
anything else) in a fashion that is secure is considerably more difficult. 
Would you agree?

> Given the non-must language and "security is not addressed" phrases in
> most RFCs,

Most RFC's aren't very relevant.

One that is relevant is RFC-2487: "SMTP Service Extension for Secure SMTP 
over TLS"; anyone care to offer an independent review?

> as well as the complexities of interacting with other complex
> protocols (such as DNS) with their own poor design and weak documentation,
> I think the only assertion you can make is that people capable of writing
> code to specificiations have a better chance of doign it well if they're
> given specifications for secure code.

FEATURE(`nocanonify') and relay email to your ISP's mailserver rather than
doing DNS lookups locally?

> > Let me repeat a private remark I made: while a program might be easier to
> > audit because it doesn't have a lot of source code, there's little reason
> > to assume that a security problem is going to be less severe just because
> > you've removed a lot of functionality.
>
> I think you can certianly make the argument that given $programmer with
> $number of bugs/kloc, reducing kloc reduces $number.  Given severe/bugs,
> reducing bugs reduces the number of sever bugs.  Also adding in
> functionality generally needing to increase complexity, and at least
> statistically I think you can assume that you'll have less severe problems
> and problems of lesser severity when you reduce functionality/code.

Sure.  But remember that zlib is hardly a large amount of source code,
either.  A security problem in a 100 line "highly auditable" program can 
result in the same level of vulnerability that results from a bug in a more
complicated system.

Select the features that are worthwhile enough to justify the security
tradeoffs you make.

-Chuck

        Chuck Swiger | chuck () codefab com | All your packets are belong to us.
        -------------+-------------------+-----------------------------------
        "The human race's favorite method for being in control of the facts
         is to ignore them."  -Celia Green


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