Re: [fw-wiz] Re: Firewalls breaking stuff: [Was re: fwtk]

From: Paul D. Robertson (proberts@patriot.net)
Date: 07/20/02 

From: "Paul D. Robertson" <proberts@patriot.net>
To: Charles Swiger <chuck@codefab.com>
Date: Sat Jul 20 11:00:02 2002

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

Relevant Pages

  • Re: Unbreakable Encryption ? Scenarios - What encryption method would be best?
    ... DES is a well-known algorithm so there are good reasons to have a good ... > risk it by storing one of the best possible passwords (or encryption ... > Ok lets say there will be a secure channel but it will happen only ... > because the decrypting method yielded a plain text message and vice ...
    (sci.crypt)
  • at last Copleys orthodox leaf
    ... but don't monitor the protestant ... accuse me flowing in part your sympathetic neighbourhood. ... Ikram, still compiling, ... climate after we secure to it. ...
    (sci.crypt)
  • Re: Best secure surfing solution
    ... I have set up a service with companies providing secure web ... the product would have to install a keylogger. ... If we caught anyone in> IS or elsewhere in our company sniffing our communications, even if they> were encrypted, they'd get laid off or, at least, suspended. ... If e-mails are sensitive then> the sender should be using encryption. ...
    (sci.crypt)
  • Re: Best secure surfing solution
    ... I have set up a service with companies providing secure web ... the product would have to install a keylogger. ... If we caught anyone in> IS or elsewhere in our company sniffing our communications, even if they> were encrypted, they'd get laid off or, at least, suspended. ... If e-mails are sensitive then> the sender should be using encryption. ...
    (alt.computer.security)
  • Re: Symmetric encryption algorithm with group like properties
    ... >> Solutions that exist today are not as secure as they can be. ... I wouldn't expect more than PGP / GPG type encryption, ... > versions - with the key, protected by RSA encryption under a RSA public key ... > Alice needs a secure decryption mechanism to read her emails, ...
    (sci.crypt)