pop 110/995, imap 143/993 ?

[Peter]

>> Lest anyone think STARTTLS MITM doesn't happen,
>> 
>> https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/

Right, the attack does happen, but it can be prevented by properly
configuring the server and client.

>> Not only for security, I prefer port 993/995 as it's just plain
>> simpler to initiate SSL from the get-go rather than to do some
>> handshaking that gets you to the same point.

Simpler from a protocol perspective, yes, but not from a configuration
perspective.  A separate port requires more firewall configuration,
requires listening on more one port if you need to accept both plain
text and encrypted connections and requires that port to be allocated by
IANA.  Since dovecot, postfix and many other servers already support
STARTTLS out of the box, sometimes with *less* configuration for it than
the corresponding TLS-only protocol, I would certainly say it's not any
simpler from a configuration perspective.  That said, neither one is
terribly difficult to configure.

> Frankly, after reading the above link and some more info on the
> internet on the subject, I am now wondering why do we bother at all
> with STARTTLS for imap, pop3

Certainly I would agree that it's not needed here, but I do not have a
real issue with it, either.

> and even smtp

...because SMTP never worked over port 465.  465 is an alternate
submission port (despite the name) and no MX server will connect to it.
MX to MX traffic always has to happen on port 25 and so the only way to
encrypt the stream is via STARTTLS.

> (and by the way, port 465
> for SMTP + SSL/TLS *is* indeed deprecated officially)?

Yes it is, and I think there was some confusion in this thread earlier
about 993/995 not being official, they *are* official, but 465 is not
which is probably what led to the confusion.

> It would
> appear that STARTTLS is significantly more vulnerable to MITM attacks
> than plain SSL/TLS for all the above protocols. Is the slight extra
> convenience of opportunistic encryption really worth the substantial
> loss in security?

I would not say significantly.  If the client is configured to require
encryption and to validate the resulting cert from the server then any
MITM vulnerability of STARTTLS is fully mitigated.  A MITM attack is
only an issue if the client is configured for opportunistic encryption.
Note that the server side should be configured to require encryption on
as well, but the important thing is that the client requires it.

I would like to point out that Thunderbird has not offered opportunistic
encryption in its setup for a number of years now, and I think that
other clients likely do not as well, so the MITM attack vector is only
an issue on older clients that are likely insecure for other reasons as
well.  Even on those (older) clients you can likely configure them to
require encryption, though.

> If I read this correctly, starttls will fail due to the MITM attack.
> That is the client knows security has been compromised.

No, the attack vector is for a client that has encryption set to may.
The MITM will either do a plain text connection to the server and strip
the STARTTLS capability from the initial server response so that the
client does not see it and degrades to plain text, or it will connect
via STARTTLS but tunnel that connection to plain text itself, not
offering STARTTLS to the client.  In either case the client, if
configured for opportunistic encryption will happily make the plain text
connection to the MITM, or it will refuse the connection if it's
configured to require encryption.

> Using
> SSL/TLS, the MITM can use SSL stripping. Since most Postifx conf use
> "may" for security, the message would go though unencrypted.
> Correct???

Not really, no.  Postfix is set to "may" by default, but this setting is
only really used for MX to MX connections because of the number of MX
servers that do not support TLS at all.  If you look at master.cf at the
commented submission service, which is what you would uncomment for
submission, you will see that it is configured to not only require
encryption but it also will refuse to offer or accept SASL AUTH on a
plain text connection.

> Is there something to enable for perfect forward security with
> starttls?

This is actually a client-side issue, but it is pretty much mitigated by
the vast majority of modern clients by the fact that they no longer
support opportunistic encryption.  You either have to select plain text
or encrypted, there is no, "encrypt if it is supported" setting any more.


Peter