On 2020-06-21 08:19:15 -0700, Kevin J. McCarthy wrote:
> This has been a bad week and I'm tired. Sorry, I understand your point now.
>
> I think you are right. I'm protecting against *nothing* by inserting a
> $ssl_starttls prompt for "* PREAUTH" because the MITM can just as easily
> insert "* OK" and strip the STARTTLS capability.
>
> So the prompt is just an annoyance because the user really needs to set
> $ssl_force_tls to stop all this nonsense.
Well, there's still something that isn't clear. When the user uses the
"imaps" protocol, I assume that the connection needs to be encrypted,
whatever the value of $ssl_force_tls (and $ssl_starttls, but STARTTLS
must not be used in this case). How is this handled? If I understand
correctly, that "!idata->conn->ssf" below.
> The code should really be just:
>
> else if (ascii_strncasecmp ("* PREAUTH", idata->buf, 9) == 0)
> {
> #if defined(USE_SSL)
> /* Unless using $tunnel, an unencrypted PREAUTH response may be
> * a MITM attack. Abort if $ssl_force_tls is set. */
> if (!idata->conn->ssf && !Tunnel && option(OPTSSLFORCETLS))
> {
> mutt_error _("Encrypted connection unavailable");
> mutt_sleep (1);
> goto err_close_conn;
> }
> #endif
> [...]
> }
>
> I'd appreciate other's comments. I'm plan on making another stable release
> in a couple days and want to get this right.
The $ssl_force_tls option should also be clarified, e.g. when "imaps",
"pops", etc. are used, but also concerning tunnels.
BTW, the $tunnel option should be clarified too. If I understand
correctly, there will be no attempt to use STARTTLS with a tunnel,
so that the encryption needs to be done by the tunnel itself. The
example uses "ssh", but that's not explicit.
--
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)
