Re: [Full-disclosure] Python ssl handling could be better...



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/



Relevant Pages

  • Re: [Full-disclosure] Python ssl handling could be better...
    ... I hear the blackhats cackle as you switch to telnet. ... please remember that to execute a MITM you actually have to be in the ... DNS cache poisoning ... note that MitM is precisely one of the types of attacks ...
    (Full-Disclosure)
  • Re: [Full-disclosure] Python ssl handling could be better...
    ... assertion that "O= O" ... NETBIOS name poisoning => Don't ever use netbios for anything ... Ok great, but by comparing MitM with sniffing, we're already assuming ... implementation make alteration of packets harder than observation of ...
    (Full-Disclosure)