[dovecot] Re: Some experiences

[David E. Storey]

On Sun, 2003-01-05 at 00:30, Amelia A.Lewis wrote:
> > Not to be confrontational at all, but I'm very curious as to why you 
> > have such an aversion to SSL/TLS for IMAP access?  I think actualy an 
> > entirely encrypted transport for something as (possibly sensitive)
> > email is a good thing.
> 
> That's exactly why.
> 
> TLS doesn't secure email.

=)

if email was secure, I wouldn't be spending a truly significant amount
of time dealing with spam.  But you're right in saying that TLS/SSL does
not create a truly end-to-end secure email solution. Then again, neither
does dovecot by itself. Nor should it. It should do one thing and do it
well.

While digest-md5 is fairly secure from a transport perspective, it's a
nightmare on the server side. In order for it to work, you've got to
store account passwords in plain text on the server. In my opinion, this
is "plain" wrong. (pun intended) Passwords should be hashed: even for
closed systems. The fallacy lies with the wetware and people tend to
forget passwords. Therefore, a lot of people have only one (or a set of)
password(s) for everything they do. You can lobby against it, but people
can be a hard species to change. If an attacker (or administrator)
gained access to the database that a system relied upon for
authentication (in the context of md5-digest), not only is that system's
(or application's) security compromised for every other user, but so are
many, many other systems that that user accesses. With hashed passwords,
my users don't have to trust me to be honest enough not to look, but I
can still reset their password.

TLS/SSL is merely a mechanism to provide privacy. In my case, I want my
PLAIN password to remain private across a transport session. As a side
note, most SSL/TLS sessions tend to use rc4 for their cipher. WEP uses
rc4 too. I'm not that familiar with the details of SSL/TLS (and I just
skimmed over RFC2246), so I might be talking out of the wrong hole, but
as far as I know, it doesn't renegotiate keys during long sessions like
IPsec or OpenVPN do. Think about that next time you spend all day with
an IMAP-over-SSL connection open, transferring megabyte after megabyte
of email around.

Personally, I just use stunnel to manage all my SSL connections. It
beats having to manage every other application's unique method for
handling SSL/TLS. I use PAM with pam_ldap to manage my logins. It just
allows for much greater flexibility than what most application
developers can bloat with their apps. (but it can also screw you up if
you're not careful.) Using LDAP has complicated things a little, but
that extra complexity has saved me BIG-TIME. (that whole idea of
replication... yeah, decentralizing your data can be VERY handy when
your system drive fails catastrophicly.)

What really ticked me off about Courier-imap is that it over-wrote my
pam-configs for imap every time I did a "make install".  I emailed Sam
about it and his take was that I shouldn't be installing the imap server
from source on a production box anyway. Now, I'm a from-source kinda
guy. Daniel J. Bernstein is a from-source kinda guy. Package management
has a high up-front cost and doesn't allow for the kind of customization
that I do on everything box that I have.... and RPM won't even compile
for me. (dpkg will and while I like the format and the design, I have
some issues with a lot of the code that has been written for it.)

I have a few production systems that handle email. Half run uw imap and
the other half, courier. dovecot seemed like a perfect solution for
converting to. It still has a couple deployment issues that I'm trying
to resolve, but I'll probably bring them up soon enough. (some of which
have already been addressed since my last attempt)

so anyway... first time poster, had to make my comments. Am I speaking
to the choir?
d!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20030105/aa493b50/attachment-0003.bin>