Re: IMAP- how to protect a server?

["Steven M. Bellovin" <smb () research att com>]

In message <Pine.SO4.4.02.9906031134080.15597-100000 () carerra corp vicinity com>
, "Aaron D. Turner" writes:
> Hmmm... I guess this brings up a good question.  How good are the SSL
> implimentations?  My understanding was that SSL was pretty solid.  
> Sure I could give all my users SecurID tokens and SecuRemote to access
> email, but I'm going to get a lot of phone calls at 3am from pissed
> off Sales people traveling in Europe who lost it or forgot how to use
> the dumb thing.
>
> Also, putting the IMAP server in a DMZ may protect my other servers
> and it from them, but it doesn't solve the issue of securing the data
> on the mail server itself.  If the IMAP server has a buffer exploit
> then I'm kinda hosed no?  One person suggested a proxy to protect the
> server, but then I got to thinking- how does the proxy inspect the
> content of the packets if they're encrypted?  Or does the fact that
> the connection is encrypted make the buffer exploit moot?
>
> The more I think about it the more confused I get.  I know some one on
> the list has actually done this- secure an IMAP server (it's content
> and the connection between it and the clients).  It's not like IMAP is
> some wacky unused protocol that only runs on Atari 2600's.
There are several separate pieces to this problem.  Bear in mind that
there are no perfect solutions, merely a tradeoff between different sorts
of risks.

First -- *no* application is inherently "absolutely secure".  It doesn't
matter if it's a host-based application or an application-aware proxy on
a firewall.  Applications are programs, and are therefore buggy.  One can
hope that firewall applications are written by more security-conscious
programmers -- but frankly, I wouldn't count on it.

Second -- if the IMAP server is compromised, the mail folders on it are
at risk.  That's going to be true whether the server is inside or outside
the firewall.  If the only access to that server is the IMAP port, in that
respect it doesn't matter where you put it; the purpose of the machine is
to offer up IMAP, which will be just as risky inside or outside the firewall.
You may be better off with it outside, though, for one reason:  a failure
won't endanger the rest of your inside machines.

There was an important caveat in that analysis, though:  I specified that
the "only access" be via IMAP.  That, of course, ignores the question of
how mail is to be delivered to the IMAP server.  Do you trust SMTP clients
that outsider access?  I have serious qualms there, though I haven't heard
of any serious sendmail holes lately.  And there are other choices, such
as postfix.  Finally, you could write your own program that would "pull"
the mail from the inside.  (Of course, you still have to have *something*
listening to external smtp.)

Call this the fundamental law of firewalls:  an application whose purpose
is access by outsiders can't be protected by a firewall.  A corollary is
that a machine that runs only such applications can't be protected by a
firewall, either.

You specified that you want to use SSL to protect access.  SSL can do two
things:  encryption and authentication.  Which do you want?

Encryption is the easy one; however, an encrypted channel between a hacker
and a buggy application will still let the bad guys in.  If you're using
client-side certificates, SSL can provide access control; in that case,
however, you're betting the complexity of the SSL implementation (and
hence its correctness) against the complexity of the IMAP implementation.
Certificate access does have the advantage that users aren't sending their
passwords to a possibly-compromised application; an easy work-around there
is to make sure that different passwords are used for email access than
for login.  (Also caution your users that they should check the certificate
of the server after connecting but before they type their password.  Then
enforce that by using a different certificate one time out of a hundred, and
reaming out the users who don't notice...)

Is the SSL certificate-checking code likely to be complex?  Yup.  IMAP?
Yup.  Is there a clear winner?  Nope.

What, then, should you do?

The best choice is to get out of the game entirely.  For example, you may
be able to write a simple IMAP authentication program that runs outside the
firewall; if authentication succeeds, let it log in to the real IMAP server
on the inside.  Using SSL is still a good idea -- there are serious threats
of session hijacking and data compromise.  But there is still complexity
in that part of SSL (as, indeed, in any cryptographic module that handles
X.509 certificates).  You're still at risk if someone can compromise an
account, and then compromise the IMAP server.  It isn't clear to me how
great a risk that is.  If you're afraid of that, follow another poster's
advice and have the real IMAP server separated from your other inside machines
by a firewall.