28 Oct
2011
28 Oct
'11
1:02 p.m.
On 28/10/11 23:35, 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. 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
I'd say it'd be worst, simply because there is a major difference
between rejecting a connection and having an app silently fall back to
non-encrypted which could be the case here if the software was coded
only slightly differently. At least with an encrypted connection it'd be
all or nothing.
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. 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?
So why is it the ISP/celco is doing deep packet inspection
here if
simple port blocking is the obvious solution?
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.
I could be facetious here and argue
the difference between encryption
and ssl/tls, you don't need ssl/tls to do encryption, firefox could have
a plugin to handle some other exchange with your embedded server.
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.
And this is why we end up with insulin pumps able to dish out lethal
doses and pacemakers or similar devices able to give a lethal shock or
be turned off, because security on embedded devices wasn't considered
critical.
http://go.theregister.com/feed/www.theregister.co.uk/2011/10/27/fatal_insul…
People need to learn that encryption is VERY important, especially on
embedded devices.