On 2011 October 28 Friday, Duane wrote:
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.
See
http://rfc.net/rfc2817.html for STARTTLS on HTTP.
Andy
--
Dr Andy Parkins
andyparkins(a)gmail.com