> On Feb 12, 2018, at 10:58 PM, Peter <pe...@pajamian.dhs.org> wrote:
> There is one case that I can think of. Older clients (Thunderbird comes
> to mind) offered an opportunistic STARTTLS setting, so that if the
> server offered TLS it would connect with TLS but if not it would
> continue to connect via plain text. Such a client in this setting could
> be subject to a MITM attack even if the server is configured to only
> allow STARTTLS connections. The MITM would simply connect to the server
> via STARTTLS but not offer the client the option.
> Note that newer versions of Thunderbird (I believe for several years
> now) do not offer this opportunistic STARTTLS setting, so if you set it
> to connect via STARTTLS it will simply not work at all if STARTTLS is
> not offered, thereby mitigating this attack angle. Also setting an
> older client to require encryption would mitigate it as well.
Sorry, you're right, the client has to enforce TLS, whether implicit
or not. Some clients try multiple ports and multiple operating modes,
so might also try port 25 in the clear, 465 with TLS and 587 with or
without STARTTLS. Such clients are subject to MiTM. The server
should also insist on TLS, to better train its clients, but the
primary burden to ensure security is on the client.