Full Disclosure 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 ways, including: * 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. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... Tim (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... Tim (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 07)
- Re: Python ssl handling could be better... Valdis . Kletnieks (Mar 08)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... Tim (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... bk (Mar 02)
- Re: Python ssl handling could be better... Marsh Ray (Mar 03)
- Re: Python ssl handling could be better... Jeffrey Walton (Mar 03)
- <Possible follow-ups>
- Re: Python ssl handling could be better... Michael Krymson (Mar 04)
- Re: Python ssl handling could be better... bk (Mar 04)