full-disclosure - Re: Python ssl handling could be better...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 2 Mar 2011 15:27:10 -0500
From: Charles Morris <cmorris@...odu.edu>
To: Tim <tim-security@...tinelchicken.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: 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/