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]

Message-ID: <20110302173510.GP2141@sentinelchicken.org>
Date: Wed, 2 Mar 2011 09:35:10 -0800
From: Tim <tim-security@...tinelchicken.org>
To: Charles Morris <cmorris@...odu.edu>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Python ssl handling could be better...

> > - ENCRYPTION IS POINTLESS WITHOUT AUTHENTICATION
> > BTW there really isn't a security difference between encrypted-but-unauthenticated traffic and just plain unencrypted traffic.  The only "attacker" you're defeating is a casual observer,
> 
> Fail. I hear the blackhats cackle as you switch to telnet. There are a
> million and one attack scenarios where what you have is an observer,
> please remember that to execute a MITM you actually have to be in the
> middle of something. That's A LOT more difficult than configuring a
> SPAN port and running snort. Especially so when you have to be
> invisible... you can't just waltz around changing routing tables or
> physically sticking a server on top of a rack of switches and expect
> not to be noticed.

I don't think you're quite catching on here.  In some practical sense
performing man-in-the-middle attacks is "harder" because of the
technical challenge of managing other people's packets without
breaking things or being noticed.  But in a security sense, they are
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.  There are automated tools for all of
these.  Once you've redirected traffic, selectively doing the MitM on
SSL is also very easy, as there are more automated tools out there for
this.

Finally, note that MitM is precisely one of the types of attacks
SSL/TLS is designed to prevent.  When you consider the complexity and
difficulty of the types of cryptographic attacks on the protocol and
its PKI that garner headlines these days, you should quickly realize
that a simple MitM isn't in the same league of difficulty.  Reconsider
your view on how hard it is.  Try it out some time for yourself.

tim

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/