Hi,
The following in imap/imap.c is not clear about the security
implications:
/* An unencrypted PREAUTH response is most likely a MITM attack.
* Require a confirmation unless using $tunnel. */
If I understand correctly, this cannot be a MITM attack if $tunnel is
used (perhaps PREAUTH could be returned by bare IMAP servers that do
not support encryption and authentication, e.g. because it is used in
a tunnel?). In this case, this should be rewritten:
/* Unless using $tunnel, an unencrypted PREAUTH response is most
* likely a MITM attack and requires a confirmation. */
Otherwise one may wonder why nothing is done when using $tunnel.
if (!idata->conn->ssf && !Tunnel)
{
if (option(OPTSSLFORCETLS) ||
(query_quadoption (OPT_SSLSTARTTLS,
/* L10N:
Gitlab ticket #246 identified a machine-in-the-middle attack
by sending a "PREAUTH" response instead of "OK". STARTTLS
is not allowed once you are authenticated, so this would be
a clever way to prevent encryption, and talk to the MITM instead.
This prompt is based on the quadoption $ssl_starttls. The
default is "yes" which will automatically abort unencrypted
PREAUTH. But if the user changes to ask-yes or ask-no, this
prompt will occur instead to warn them that the connection is
an unusual "PREAUTH" and is unencrypted. The warning is terse,
so translator feedback and suggestions most welcome.
*/
_("Abort unencrypted PREAUTH connection?")) !=
MUTT_NO))
{
mutt_error _("Encrypted connection unavailable");
mutt_sleep (1);
goto err_close_conn;
}
}
This may be too technical for the user who doesn't know the protocol
and may not be able to deduce what this means in terms of security.
I would suggest something like:
Possible MITM attack. Abort unencrypted PREAUTH connection?
Unencrypted PREAUTH connection requested: possible MITM attack. Abort?
And there should be something about that in the manual. I suppose that
there can be false positives in specific cases, such as a connection
to a local socket (which may or may not be a SSH tunnel to a remote
IMAP server).
Now, instead of replying PREAUTH, a MITM attack could also reply OK and
not advertise STARTTLS, in which case $ssl_starttls will be ignored. So
I think that the above change does not really solve the security issue.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
