Sam Clippinger wrote:
You could get close to this by using SMTPS (SMTP over SSL, so the entire
connection is encrypted) and requiring authentication. The security
would be as strong as SSL, which is pretty good.
I'd rather stay away from that, as SMTPS is deprecated.
While I like the idea of requiring encryption for authentication, I'm
concerned that there's no way to communicate that requirement to the
client. During SMTP, the server advertises its capabilities to the
client, which is where authentication and TLS are offered. If TLS is
started, the server is allowed to advertise a different set of
capabilities to the client after encryption begins. But there's no way
to say Authentication is not allowed only because TLS is not started;
start TLS and you can authenticated. spamdyke would have to simply
refuse to authenticate without TLS (and possibly reject all
unauthenticated connections).
I don't know the details of implementing such a feature, and don't
really care how it's implemented (so long as it works!). I've learned
since posting this request that there's a patch for qmail which causes
it to refrain from advertising authentication until TLS is started. That
is perhaps the correct way to do it.
So, disregarding the support headaches for sysadmins who use such a
feature, I could add a require-tls value to the smtp-auth-level
option. That would be pretty easy.
I'm wondering if this is really mutually exclusive of the other
smtp-auth-level values. I guess requiring TLS would also imply the
always behavior as it's presently defined. Perhaps adding
always-require-tls would be a clearer value for this option.
However, CRAM-MD5 is actually pretty secure. It's a challenge/response
protocol, which means the password is never sent over the wire in any
form. The server sends a challenge, which is just a big binary value
(based on the server's name, the time and random numbers, so it's not
predictable). Both the client and the server encrypt the challenge
using the user's password as the encryption key (using the MD5
algorithm, hence the name). The client sends the result back to the
server (the response), which the server compares to the value it
calculated. If the two values match, the client and the server must
have used the same password during the encryption, so the client is
authenticated. Thus the security is as strong as MD5, which is pretty
good. (IIRC, some researchers have demonstrated a few potential
weaknesses in MD5 but nothing that would threaten this scenario in any
practical way.)
Thanks for this explanation Sam. Besides any concerns one might have
about MD5's weakness though, CRAM-MD5 also requires the password(s) be
stored in clear text, which is not acceptable in some situations, and is
generally not a good practice from a security standpoint.
-- Sam Clippinger
Thanks as always, Sam. Spamdyke is unbelievably terrific!
Eric Shubert wrote:
While spamdyke can do both TLS and authentication, I don't see an option
for requiring TLS when authenticating. I see smtp-auth-level settings of
ondemand-encrypted and always-encrypted, but these -encrypted settings
appear to refer to cram-md5, and they effect offering the protocol, not
enforcing it. Also, my understanding is that cram-md5 is somewhat
old-style, and less secure than TLS/SSL.
It would be nice to be able to enforce from the server a policy of
requiring TLS to be used with authentication, so that clients don't
inadvertently send passwords in the clear. IOW, a setting that would
check to be sure TLS was activated before processing any authentication
command (possibly with the exception of cram-md5). It'd be great if this
could work regardless of whether qmail or spamdyke is handling the
encryption and/or authentication.
Thanks Sam for all your great work on spamdyke.
--
-Eric 'shubes'
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
