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

["Paul D. Robertson" <proberts () patriot net>]

On Fri, 19 Jul 2002, Charles Swiger wrote:

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

It doesn't have to be common to be a bad thing, which meets: ""stupid" 
rather than important functionality which improves security? (Your 
criteria)"

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

As I said further down, there are ways to architect around it, but that 
doesn't make it right for every situation.

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

You're going from "external mail at all" to "Relay and read mail 
externally"- which are two very distinct things with signifcantly 
different risk profiles.

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

Actually, remote mail only isn't all that common, people don't tend to go 
for service level encryption versus VPN access.  Remote access brings with 
it a number of issues that aren't there with local access, and there's an 
associated cost and risk with doing it.  For instance now either your mail 
relay/reader box has to hook into the current authentication scheme, or 
have it's own.  If it has its own, then it's got to be maintained with 
hires and fires.  Now people will send and receive mail on machines that 
the company doesn't own which may be trojaned...

Also, the ability to relay mail is normally predicated by the ability to 
read it, and if we want a cespool of insecurity, we should go to mail 
client protocols.  That's a dependency chain that's best served with a 
generic secure tunnel if it must be done at all, which negates the need 
for a service level tunnel. 

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

No, but I'm claiming that there's not much of an organizational gain to 
providing service level encryption versus IP level generic 
encryption if you must provide remote access.

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

Plain text is better under circumstances where you're doing things with 
the data that don't have the ability to get the key, where local legal 
requirements make encryption prohibitive, where you want someone to access 
the data, where the transport mechanism really *needs* the efficiency of 
data compression (do a lot of satcom and you'll understand that point 
painfully.)

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

To some extent- I'm not sure "very easy" counts if the thing being written 
is going to interoperate well with other SMTP systems (for example 
sending mail to a domain with the PIX bug- and this very mailing list- 
where you'd expect people to have enough clue to maintain their firewalls 
enables the PIX workaround a fair ammount.)

> > Given the non-must language and "security is not addressed" phrases in
> > most RFCs,
>
> Most RFC's aren't very relevant.

But the lack of treatment of security is relevant to most RFCs, and in 
this case we kind of start with:

RFC 821, RFC 822, RFC 1869, RFC 1521, RFC 1522, RFC 1123, 
RFC 1342, RFC 1428, RFC 2554, RFC 1425, marginally RFC 1341, RFC 1854...

(there may be one or two overlaps there, but if you're going to be doing 
an implementation that claims to have security abilities, most of those 
apply at some level, especially if you're offering any sort of content 
validation.)  Adding TLS, SSL, and SMTP Auth on top is just going to 
increase the nubmer.   

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

It's on my list of things to do eventually, but it really requires a very 
deep look at TLS itself and the auth stuff as well, which means I need 
real cleared away time (unless I can foist it off on Moskowitz, then 
review his work once they're all done fixing WEP ;) )

I will say that the dearth of response codes for potential attacks worries 
me somewhat, as does the fact that the server and the client seem to need 
to not do multiple STARTTLS commands, as does the fact that there are 
"shoulds" instead of "musts" immediately in the "you should drop things 
because you didn't like the auth or cipher" path.  It's not well-designed 
for multiple virtual domains (which really wants a change so that STARTTLS 
comes after the mail from and rcpt to's- which break the privacy model...)

As is pointed out in the RFC, nuking the STARTTLS command is a huge risk, 
and it's a trivial attack.

Beyond the 5 minute peek, it'll take significant time to do a full review, 
and take a look at two independent implementations to see where the traps 
really sit.  It's on my plate for this year, but it's not on my plate for 
this quarter.

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

That would require all mail to be relayed, kind of taking away the value 
of the TLS unless you're in an organization that only has one or two 
domains- if the intent is for employees to be able to mail to other 
employees, the privacy is probably as important as the authentication, no?

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

Can, but isn't likely to.  I think it's fair to say that programmers, and 
even to some extent teams of programmers tend to have pretty constant 
bugs/kloc numbers absent some sort of correction- so the zlib with a small 
ammount of code had major bugs, but imagine what zlib would have been like 
if it were 20M of code...

There are reasons that attackers have done things like grep for "Vixie" in 
source to identify targets[1].  Bugs in say Vixie Cron versus bugs in BIND 
correlated to code size illustrate the point IMO.

Paul
[1] That's not to say that Vixie's contributions aren't great, it is to 
say that his coding stlye wasn't defensive, but was rather feature 
oriented.
-----------------------------------------------------------------------------
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