Re: [Exim] restricting AUTH Plain/Login to TLS connections

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Derek Simkowiak
日付:  
To: Giuliano Gavazzi
CC: Sven Geggus, exim-users
題目: Re: [Exim] restricting AUTH Plain/Login to TLS connections
> >is it possible to do restrict the AUTH Plain/Login mechanism to TLS
> >encrypted connections?

[...]
> spec.txt under auth_advertise_hosts says

[...]
>        auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}


> also you might want an after the fact caution that I found somewhere
> in the docs:

[...]
> acl_check_auth:
>      accept encrypted = *
>      accept condition = ${if eq{${uc:$smtp_command_argument}}\
>                          {CRAM-MD5}{yes}{no}}
>      deny   message   = TLS encryption or CRAM-MD5 required


    According to the docs, Exim is always ready to accept an AUTH
command.  Therefor, the above perform two different tasks.


    The first one, which sets auth_advertise_hosts, won't advertise
"AUTH" in response to EHLO, unless the EHLO is given over a TLS (aka SSL)
connection.  Not seeing AUTH advertised is enough to prevent most client
programs from submitting the username and password, and so, in that
fashion protects endusers from having their passwords fly in the clear.


    The second one, which defines an ACL for the AUTH command, will
cause Exim to refuse the AUTH command unless it's over SSL (or the
password is encrypted via CRAM-MD5).  If you do not have this on, Exim
would still accept the AUTH command (even though it was not advertised to
the client).


    I don't know which (if any) email clients would send the AUTH
command, even though it was not advertised.  But assume there was one, and
that my boss used it.  If I wanted to learn my bosses email password
(which may actually be a password to many other things, too, given the
current trend towards 'Single Sign On') all I would need to do is


1. Sneak into his office when he wasn't there
2. Uncheck the "Use SSL" box in his account configs
3. Sniff his network connection while his client checked for mail

    Using the acl_check_auth above would protect your users from this
scenario.  Hmmm... on second thought, it would protect your users from
this scenario only if the client didn't send its unsoliticed AUTH command
as type PLAIN, which includes the cleartext password.  (If there are any
clients out there which actually do this, they should be boycotted.)


    I have only tested MS-Outlook 2002, which only submits the
username/password if AUTH type "LOGIN" is advertised.



    So in short: use both.  :)


--Derek