Re: [spamdyke-users] Encryption policy enforcement
On 01/27/2012 04:38 PM, Sam Clippinger wrote: > Interesting suggestions. The first one, logging how many users authenticate > without TLS/SSL, is basically already there. Since the log messages already > show both the authenticated user and the encryption status, you should be > able to parse through them to find people who authenticated in the clear. > That percentage is probably going to be pretty high, especially among Outlook > users. I hadn't thought of that. You're right, it's in there. :) Outlook'03 doesn't support TLS, so I'm sure you're right there as well. > Implementing a filter to require TLS for authentication shouldn't be too > hard. Lots of servers already do this -- they either don't advertise > authentication until after TLS starts OR only advertise challenge/response > authentication until after TLS starts. spamdyke could do that too, as well > as stripping out (and blocking) cleartext authentication offered by a patched > qmail. I'd love to see this. It would certainly help to enforce a good security policy (no clear text passwords). Of course this would also require spamdyke to be installed on the submission port 587, but that's something I'd be willing to do if this option were available. Having spamdyke on port 587 will be needed also for some other future enhancements such as auto-whitelisting, so I don't think this is a big deal. > Implementing a filter to require TLS for every connection could be > problematic. Remote servers (as opposed to mail clients) wouldn't understand > the problem and a lot of mail would bounce. Even if a remote server is > capable of doing TLS for outbound connections (many aren't), convincing the > admins of those remote servers to make the change would be a nightmare (to > say the least). If always-on encryption is really what you want, why not > just use SMTPS? This was somewhat of an afterthought. Enforcing this would indeed be a little impractical, but I'm a little surprised at how many servers are actually using TLS already (msn, gmail, as well as many small ones). Since the log messages have all the data required already to do analysis, this isn't a high priority. I just thought it might be a nice feature for companies who need a high degree of security. If the filter would be easy to code, I think it'd be a nice touch (not that it'd get much use). If the code would be troublesome, then forget it. Of course smtps (465) could be used internally, but there's no way to enforce an encryption policy externally (unless you write the filter). ;) Thanks again Sam for your great work with spamdyke. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Encryption policy enforcement
Interesting suggestions. The first one, logging how many users authenticate without TLS/SSL, is basically already there. Since the log messages already show both the authenticated user and the encryption status, you should be able to parse through them to find people who authenticated in the clear. That percentage is probably going to be pretty high, especially among Outlook users. Implementing a filter to require TLS for authentication shouldn't be too hard. Lots of servers already do this -- they either don't advertise authentication until after TLS starts OR only advertise challenge/response authentication until after TLS starts. spamdyke could do that too, as well as stripping out (and blocking) cleartext authentication offered by a patched qmail. Implementing a filter to require TLS for every connection could be problematic. Remote servers (as opposed to mail clients) wouldn't understand the problem and a lot of mail would bounce. Even if a remote server is capable of doing TLS for outbound connections (many aren't), convincing the admins of those remote servers to make the change would be a nightmare (to say the least). If always-on encryption is really what you want, why not just use SMTPS? -- Sam Clippinger On Jan 27, 2012, at 2:13 PM, Eric Shubert wrote: > In the "Also ToDo" section of the TODO.txt document, there exists this item: > Add the ability to require TLS/SSL before authentication is allowed > (e.g. a "require-tls" value for "smtp-auth-level"). > > This is one that I requested some unknown time ago (I didn't even > remember requesting it yet, so I'm glad this list exists!). > > I've done a little more thinking about this and would like to modify the > suggestion a bit, and hopefully escalate its status to the Highest > Priorities list as well. > > First, I'd like there to be two options, one which would only log > attempts to authenticate w/out TLS/SSL, allowing the administrator to > try out the settings and see what the impact would be by examining the > logs. The 2nd option would actually enforce the policy, rejecting the > login attempt as well as logging the event. > > The importance of this capability is not so much that messages are > encrypted, as passwords. Without this feature, there's no way (that I > know of) to ensure that passwords aren't sent in the clear. Of course an > encrypted authentication method (cram-md5 or digest-md5) could be used > without TLS. That would suffice, but those methods have problems of > their own (storing clear text passwords), so I think the simplest and > best way of providing the ability to ensure that passwords are not sent > in clear text is to require TLS before authentication. > > One more thing. Someone might want to enforce encryption on all > messages, not only before authentication. This would mean that all > inbound messages would need to use TLS, period. I think this might > require an additional config parameter, which would have 3 values, > none|log|enforce. So this would be an additional enhancement (so long as > we're on the subject of enforcing TLS). > > If anyone has any thoughts about this, we'd like to hear them. > > As always, thanks for all your great work with spamdyke, Sam. > > -- > -Eric 'shubes' > > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Encryption policy enforcement
In the "Also ToDo" section of the TODO.txt document, there exists this item: Add the ability to require TLS/SSL before authentication is allowed (e.g. a "require-tls" value for "smtp-auth-level"). This is one that I requested some unknown time ago (I didn't even remember requesting it yet, so I'm glad this list exists!). I've done a little more thinking about this and would like to modify the suggestion a bit, and hopefully escalate its status to the Highest Priorities list as well. First, I'd like there to be two options, one which would only log attempts to authenticate w/out TLS/SSL, allowing the administrator to try out the settings and see what the impact would be by examining the logs. The 2nd option would actually enforce the policy, rejecting the login attempt as well as logging the event. The importance of this capability is not so much that messages are encrypted, as passwords. Without this feature, there's no way (that I know of) to ensure that passwords aren't sent in the clear. Of course an encrypted authentication method (cram-md5 or digest-md5) could be used without TLS. That would suffice, but those methods have problems of their own (storing clear text passwords), so I think the simplest and best way of providing the ability to ensure that passwords are not sent in clear text is to require TLS before authentication. One more thing. Someone might want to enforce encryption on all messages, not only before authentication. This would mean that all inbound messages would need to use TLS, period. I think this might require an additional config parameter, which would have 3 values, none|log|enforce. So this would be an additional enhancement (so long as we're on the subject of enforcing TLS). If anyone has any thoughts about this, we'd like to hear them. As always, thanks for all your great work with spamdyke, Sam. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
