On 22/08/17 01:56, Peter wrote:
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.
Seriously? So one more port to allow through the firewall is somehow
more complex than making sure the server and/or the client is configured
to refuse falling back to plaintext communication - and testing various
clients and server flavours to make absolutely sure that they do what
they are supposed to be doing and don't fall for a MITM attack? At least
with plain SSL/TLS ports, you know for sure that if you are connected,
it is definitely encrypted.
</snip>
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.
Yes - and you have a lot of "if's" above - and that is exactly what
makes it more vulnerable in practice - where you have to make absolutely
sure that your particular version of your particular software definitely
behaves like that - while with plain SSL/TLS it just works and there is
no checking needed or "if's". In real life, that makes STARTTLS less secure.
