28 Oct
2011
28 Oct
'11
11:27 a.m.
On 28/10/11 21:51, Andy Parkins wrote:
On 2011 October 28 Friday, Duane wrote:
This thread is all the proof you should need of the potential of MITM
attacks, here both the client and server support it, however due to a
3rd party messing with packets, encryption is utterly useless.
Why do people bother with starttls, bound to be
open to all sorts of man
in the middle attacks, this is why nobody ever bothered using it for
escalating HTTP connections.
I don't think that's true.
The starttls command could indeed be mitm-attacked, but to exactly the same
extent so could the initial TCP negotiation to SSMTP port 465. Think of
STARTTLS as being equivalent to the TCP SYN packet and you can see it makes no
difference at all how the initial unencrypted contact is made.
The SSL/TLS negotiation includes a certificate phase for exactly this reason.
There's no more wrong with STARTTLS protocols than there is with running a
service on a different port to mark it as encrypted. The only potential problem is allowing clients that
aren't encrypted: you can
either say "that's their problem", or require that the server deny all
client
commands_except_ STARTTLS on an unencrypted connection. To be honest, I have
no idea why we have this constant dual-allocation of ports for single
services. It's a waste of well-known port numbers; http/https included.
Exactly, we should only bother with HTTPS/POP3S/IMAPS/SSMTP and do away
with clear text communication altogether...