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 [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
