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

[Paul Robertson <proberts () patriot net>]

On Fri, 19 Jul 2002, Charles W. Swiger wrote:

> Yes, there are times when you have to decide between security and 
> functionality or backwards-compliance with older protocols.  Is there any 
> convincing reason to believe that Cisco's MailGuard SMTP implementation is 
> more secure just because it breaks ESMTP?

A poor implementation, or poorly thought out implementation isn't evidence 
that a concept is or isn't flawed.  I'm sure that we can all find 
canonical examples of "security software" that should have been 
deployed[1].

> > Historically, I've never felt remorse over violating RFCs where they are 
> > stupid.
>
> 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.)

> 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.  
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.

> 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. 
Given the non-must language and "security is not addressed" phrases in 
most RFCs, 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.

> Microsoft wasn't willing (or competent enough) to implement SMTP according 
> to the RFCs, either.  Oddly enough, M$ Exchange and M$ Outlook aren't well 
> known for the security improvements they've brought to electronic mail.  :
> -)

Microsoft is known for implementing a lot of protocols- I don't know 
they're known for security improvements they've brought to $anything.

> 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.

> If you really try you can screw up SMTP badly enough to lose mail, but it'
> s easier and more secure to disconnect the ethernet cable on the MX box, 
> or filter port 25 entirely.  It's not clear that Cisco's SMTP 
> implementation is any less broken than that of Microsoft Exchange.

I think you can pick a particular snapshot of either and show that one is 
more broken than the other.  Given the latest version of both, I know 
where my money would be (and it'd be a functionality/code side driven 
bet.)

Paul
[1] I've dealt with enough broken PIXen to have the personal opinion that 
the feature should be removed, shot, folded, spindled and mutliated.  The 
fact that Postfix has a PIX-specific work-around so that mail can be 
delivered downstream of PIXen with the mailguard on should illustrate the 
point.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

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