mailing list archives
Re: Python ssl handling could be better...
From: Charles Morris <cmorris () cs odu edu>
Date: Wed, 2 Mar 2011 15:27:10 -0500
the same. Another way to look at it is O(MitM) = O(sniff). There may
be some implementation details that make MitM harder, but it's within
a constant factor.
To illustrate this point, we merely need to search the web for MitM
tools. At the network layer, we could achieve this in one of numerous
* DNS cache poisoning
* ARP poisoning
* routing protocol poisoning (many kinds)
* ICMP router redirects
* NETBIOS name poisoning
The list goes on, I'm sure.
The list does go on. However, I completely disagree with your
assertion that "O(MitM) = O(sniff)"
Yes there are many vectors to MITM at many levels, but they are
(perhaps not ALL) not only detectable but also preventable in many scenarios.
* DNS cache poisoning => Don't fail at DNS
* ARP poisoning => use static ARP tables (and before you say "who on earth does that"- I do)
* routing protocol poisoning (many kinds) => (many solutions)
* ICMP router redirects => Get filtered by firewall before they ever reach me
* NETBIOS name poisoning => Don't ever use netbios for anything
That should be fairly self-evident.
Take wireless with some mid-level encryption for example, how easy is
it to sniff wireless traffic and crack if after the fact;
versus how easy is it to do a live MITM on said traffic?
How easy is it to become a fake AP and grab new clients?
What numerous protections can we make against that sort of attack?
I think you and this rambling bk fellow misunderstand the nature of my
disagreement with you.
My statement is not that that we shouldn't be designing systems for
the "highest possible level of assurance",
my statement is that, along with everything in my previous email, it's
completely baseless and fundamentally
damaging to make the statement that:
0) "ENCRYPTION IS POINTLESS WITHOUT AUTHENTICATION"
1) O(MITM) = O(sniffing)
2) RISK(MITM) = RISK(sniffing)
3) whateverelse(MITM) = whateverelse(sniffing)
N.B. I am in complete agreement with the point of this thread; that
python's handling should be fixed.
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
Re: Python ssl handling could be better... bk (Mar 02)