pop 110/995, imap 143/993 ?

[Sebastian Arcus]

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.