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

From: Charles Swiger (
Date: 07/20/02

From: "Charles Swiger" <>
To: <>
Date: Sat Jul 20 09:47:17 2002

"Marcus J. Ranum" <> wrote:
> Charles W. Swiger wrote:
>> 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?
> OK. It seems pretty straightforward so I didn't elaborate sufficiently
> on the first pass...

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?" :-)

> The last time I downloaded the SSL codebase library it was humongous.
> I'm sure it's got more security bugs in it than a college dorm room
> has cockroaches. We just haven't found them all yet - probably because
> it's huge. So by adding SSL you're incorporating one huge thing into
> another huge thing.

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.

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

> Not only that, it's something hooked to a network
> that accepts connections from the entire planet. That's just a bad idea.

There's nothing that says you can't relay mail from an external MX box which is
not trusted to an internal MX box which is not reachable from the outside world.

Any number of mechanisms could be used, including SMTP relay from your ISP or a
machine in a screened external subnet, UUCP batching, scp/rsync, or even a
firewall-based proxy server such as yours, if you like. The advantages of ESMTP
have the most benefit for email crossing the Internet; using a less complicated
method for mail crossing an internal security perimeter would do fine.

> SMTP AUTH I have't looked at the code for, but I bet it's another
> plate of spaghetti.

Which MTA's implementation are you talking about, here? I think Claus Aussman
did sendmail's, and I seem to remember Grahm Orndorf (sp?) working on postfix.

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

> But one thing I can tell you for sure!!! If they aren't built into
> my mailer, I don't have to worry about 'em!!

I betcha the guys at Cisco thought pretty much the same. Microsoft does a good
job of the "not invented here, so I'm going to break compatibility" game too.

Frankly, existing mailers would be far easier to write and secure if people
stopped playing games with the protocol and MTA's didn't have to write
special-case mechanisms to work around firewall proxies which lose email.

> That's my whole point.

Yes. You prioritize security over functionality, which certainly reasonable
considering your background.

However, it would be an error to assume this prioritization is the best for
every situation. There are plenty of real-world situations (ie, ones measured
in dollars and/or downtime/recovery costs) where you gain more from having good
backups than from having even the world's best network security.

> I guess that's a philosophical point I haven't raised: things that aren't
> strictly necessary, if you're writing security code, are, by definition, dumb.

I agree with the principle of "minimum required functionality provides the best
security". Do you believe that there are never situations where additional
functionality is worth the potential security tradeoff?

>> 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.
> All built into the same mailer? Heck, why not throw a perl interpreter
> in there while you're at it! And make it an SSL web server, too,
> since you've already got SSL in there and it's already handling
> everything else in one process. Shoot, why not just write the whole
> thing as an apache plug-in and then it'll be _really_ secure! :)

Lots of ISPs provide web-based email access via SSL. The world would be a
better place if they could do so securely, or, at least, more securely then they
do now.

Oh-- the answer to your question is 'no'. Again, please note that I didn't
specify an implementation.

[ ... ]
> This is both laziness and a quest for perfection.
> It is the zen of knowing what is enough.

Certainly I wouldn't want to interfere with anyone's zen. :-)


Relevant Pages

  • Re: JSH: Finally some social crap answers
    ... I emailed Granville and Ribet DIRECTLY, ... SSL is actually rather new, only becoming important in the last decade or so. ... A very surprising amount of the Internet is actually not encrypted at all; DNSsec was deployed to the root DNS servers only in the past year or two, and very little email traffic is encrypted or even signed. ... The original design goals explicitly made security a lower priority than abstraction of transport mechanisms. ...
  • [NT] Microsoft SSL Library Remote Compromise Vulnerability (MS04-011, Exploit)
    ... Get your security news from a reliable source. ... condition in the Microsoft Secure Sockets Layer (SSL) library. ... the PCT 1.0 protocol is disabled by default. ...
  • RE: Checkpoint smart defance as IPS
    ... SSL is perceived by many as secure. ... Again, SSL is about privacy, not security. ... you don't understand why SSL is regarded secure. ... in order to intercept, ISP requires court order. ...
  • Not able to connect to Secure Websites
    ... Security to download updates, play online music etc. ... In the Security section of Internet Options, ... SSL and SSL 3.0 are checked ...
  • [fw-wiz] Help- Nat-t
    ... Security of HTTPS ... > Is there some possibility of a MITM attack? ... HTTPS relies on SSL / TLS. ...