On 2020-06-18 18:14:15 -0700, Kevin J. McCarthy wrote:
> This is an important security release fixing a possible
> machine-in-the-middle response injection attack when using STARTTLS with
> IMAP, POP3, and SMTP. (For packagers, I've requested a CVE and will update
> the website when I have the number).
+ /* L10N:
+ The server is not supposed to send data immediately after
+ confirming STARTTLS. This warns the user that something
+ weird is going on.
+ */
+ mutt_error _("Warning: clearing unexpected buffered data before STARTTLS");
The "before STARTTLS" is not clear. Doesn't this occur *after*
STARTTLS has occurred?
Moreover, I think that there is an error in the manual about STARTTLS,
which provides a false sense of security to users:
------------------------------------------------------------------------
9.3.357 ssl_starttls
--------------------
Type: quadoption
Default: yes
If _set_ (the default), mutt will attempt to use ‘STARTTLS’ on
servers advertising the capability. When _unset_, mutt will not attempt
to use ‘STARTTLS’ regardless of the server’s capabilities.
------------------------------------------------------------------------
But a MITM attack can occur before TLS actually starts, where an
attacker can remove the "STARTTLS" sent by the server, with the
consequence that TLS will not be used, a.k.a. STRIPTLS attack:
https://en.wikipedia.org/wiki/Opportunistic_TLS#Weaknesses_and_mitigations
https://tools.ietf.org/html/rfc7672#section-1.3.1
So a user who knows that some server supports STARTTLS and isn't
aware of this attack may think that everything will be OK and that
the connection will be encrypted with this server, while this may
actually not be the case. I think that this should be documented,
and the manual should advise users to set ssl_force_tls.
--
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)
