28 Oct
2011
28 Oct
'11
12:35 p.m.
On 2011 October 28 Friday, Duane wrote:
You've mixed your arguments up a little there.
You were saying that STARTTLS is more vulnerable to MITM attacks than a secure
port. It isn't any better or any worse. It is however better from the point
of view that we don't need as many pre-assigned port numbers and the choice
about encryption is moved to where it should be: the application layer.
Also: surely an ISP/mobile carrier is more likely to implement simple port
blocking than deep packet inspection to find out whether your mail client is
sending STARTTLS or not?
> 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.
There's no more wrong with STARTTLS protocols
than there is with running
a service on a different port to mark it as encrypted.
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. Exactly, we should only bother with
HTTPS/POP3S/IMAPS/SSMTP and do away
with clear text communication altogether...
That's a separate debate. Sounds like a pretty blunt solution to me though.
I happen to write embedded software that runs on tiny little microcontrollers
and yet provides web servers. That is only possible because we don't have to
fit a whole SSL/TLS stack in 8KiB of memory.
If you happen to care about efficiency, have a think about all the resources
(electrical and computational) that would have to be dedicated to encryption
simply to protect, say, my mobile phone's looking up of what the weather will
be tomorrow if HTTP were outlawed.
Everything has its place; including non-encrypted connections.
Andy
--
Dr Andy Parkins
andyparkins(a)gmail.com