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-comm...
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.