Unlikely full mitm over wifi
You seem to suggest in this repeat post that you have this working over a wpa network. This is a level III redirect mitm-type sniffer exploit.
This summary (below) is that which is required for a full mitm over wpa:
That you have equipment using a wpa-encrypted wifi connection to an AP, which you then force to dissociate and reauthenticate with an attacking machine. You then connect to the AP from the attacking machine (using wpa), flood the channel and use arpspoof to force the target machine to preferentially authenticate with your attacking machine (using wpa) which then handles all inbound/outbound requests, without the AP forcing a reconnection!
I doubt very much that you have done that! After all my coding of a level II station-to-station attack system I do not believe it possible. Any affirmation otherwise would promote a useful debate.
I rather suspect you are simply sniffing your own traffic and/or with a hardwire mitm at the router, albeit with original transmissions over wifi. This is not a realistic mitm attack as we know it here. It is rather, an internal proxy redirect.
I urge you to resist oversimplifying and over-claiming use of these exploits in these forums as serious reinvestigation takes a good deal of time.
I do however believe it is a worthy proof-of-concept and investigation is useful, (but not simply sniffing your own output).
Answer: from Moxie Marlinspike - Tor with SSL
Hey ********** (onryo here), By the time that a tor proxy puts
anything on the wire, it is encrypted with three "onion layers" of encryption
for each tor node in its circuit, plus the TLS encryption to the guard node.
So even straight HTTP requests that are routed through the tor network
are essentially embedded within a layer that we can't see or modify as a
local attacker. This is part of how tor provides anonymity -- as a
local observer we can't tell what the content is or where it's going.
When the traffic finally makes it to the final hop in the tor circuit,
though, the data is at that point completely unencrypted and visible to
the exit node. So while the exit node doesn't have any indication of
where it came from, it is free to observe and modify all non-SSL traffic
that is being routed through it. What I presented in DC were results
from running sslstrip on an actual exit node, not on a local network
where tor traffic was originating from. Since tor is a volunteer
network, setting this up on an exit node is not difficult.
I just gave a similar talk in Amsterdam at BH Europe, where I also
presented a tor scanning tool that I've been using to monitor exit nodes
and ensure that they are not running sslstrip.
If you have any other questions, let me know.
- moxie
----------
Thought I would share my mail from moxie
onryo
