Omer <[EMAIL PROTECTED]> wrote:
> Quite a lot of pop clients support apop (qpop, for instance).
> Granted, it's no ssh or ssl - but it's better than nothing.
Actually, one has to distinguish several security issues here:
1. Usage of encrypted versus plain-text passwords
2. Usage of different (from the system login) passwords
3. Encryption of the whole session (i.e., including the mail message body)
Theoretically speaking, as far as an email service(s) is concerned, one
shouldn't worry about (1), given that (2) is satisfied. Indeed, what would a
snooper do with one's email (== imap or pop) password? Only read his emails,
but since the email is relayed over the Internet in plain text, it doesn't
matter anyway. Or, putting it other way around, if you want privacy, use
pgp/gpg, and your correspondence will remain private whether the imap/pop
password is guessed or not. For the same reason, (3) isn't worth tinkering
with either (again, talking about email).
There is an important exception from this reasoning, though: users tend to
forget special, per service, passwords and then try to use their system
login&password pairs :). Therefore, even if the authentication fails, the
true login&password pair is exposed to the world. So still, encrypted
passwords should be preferred. This can be mostly ignored if the shell
logins are disabled on the server altogether (a good thing anyway) and
clients connect from inside a well-guarded firewall.
A good thing about Qualcom's pop server (aka qpopper) is that it can use a
separate password DB AND use encrypted passwords (APOP). A bad thing is,
only clients that understand it can work with it. On the other hand, as far
as the open source software is concerned, it's a trivial task of modifying
the authentication scheme (I once patched xfmail-1.2 to support APOP in an
hour).
> UW's IMAP server supports some sort of challange/response
> security mechanism (CRAM-MD5? I'm not sure).
It does, but then again clients should use it, too. Probably you refer to
the _name_ of the alternative password DB it can use - but unless specially
told, it will still authenticate using plain-text passwords.
> Anyhow, it's not too hard (if anything, it's darn easy)
> to get stunnel or sslwrap running and allow your to enjoy
> the benefits of encrypted email (for the paranoid, anyhow).
Now, talking generally, not just about email, the problem with stunnel (or
ssh forwarding) is that it should be setup for every service. Furthermore,
protocols without fixed port number and UDP-based connections can't be
encapsulated this way. A proper way of handling such situations may be VPN
(virtual private network). Of course, a VPN setup requires super-user access
rights on both sides of the link. There are several VPN implementations for
Linux. Among free ones, VPND and VTUN are probably the most popular. I
personally use VPND, since it doesn't require patching the kernel, though
VTUN should be faster (for the same reason, being implemented on the kernel
level). Still, performance is quite tolarable: say, with a 576-bit
encryption key and a modest 486dx2 I get more than 100KB/s for NFS reads.
Regards,
Evgeny
--
____________________________________________________________
/ Evgeny Stambulchik <[EMAIL PROTECTED]> \
/ Plasma Laboratory, Weizmann Institute of Science, Israel \ \
| Phone : (972)8-934-3610 == | == FAX : (972)8-934-3491 | |
| URL : http://plasma-gate.weizmann.ac.il/~fnevgeny/ | |
| Finger for PGP key >=====================================+ |
|______________________________________________________________|
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
