On 08/08/2017 01:48 PM, Steven Chamberlain wrote:
Further investigation shows that this happens for any destination IP address, even where there's no SSH service running:
Make a "trap" ssh server (for example on virtualbox machine without any sensitive data) and log in into it through tsocks. After that check from which ip it was logged in. This probably would be ip of the exit node.
me@eugenemolotov.ru wrote:
Make a "trap" ssh server (for example on virtualbox machine without any sensitive data) and log in into it through tsocks. After that check from which ip it was logged in. This probably would be ip of the exit node.
What if they "bridge" mitm-ed traffic to a different host?
I saw a similar ssh warning few weeks ago but I wasn't prepared to identify the bad exit. I set SafeLogging to 0 and I will enable debugging via SIGUSR2 next time this happens. Can someone confirm whether it's a good way of identifying bad exits?
On Wed, 9 Aug 2017 21:08:30 +0100 Alexander Nasonov alnsn@yandex.ru wrote:
me@eugenemolotov.ru wrote:
Make a "trap" ssh server (for example on virtualbox machine without any sensitive data) and log in into it through tsocks. After that check from which ip it was logged in. This probably would be ip of the exit node.
What if they "bridge" mitm-ed traffic to a different host?
They could feed MITMed traffic back into Tor, framing a different exit node in the process :)
You choose your own path and exit. It couldn't be any node before your chosen exit because of onion.
You can't look for incoming traffic on your ssh server to know the bad node. You have to know your chosen exit from the client end, to know the MITM.
On Aug 9, 2017 1:08 PM, "Alexander Nasonov" alnsn@yandex.ru wrote:
me@eugenemolotov.ru wrote:
Make a "trap" ssh server (for example on virtualbox machine without any sensitive data) and log in into it through tsocks. After that check from which ip it was logged in. This probably would be ip of the exit node.
What if they "bridge" mitm-ed traffic to a different host?
I saw a similar ssh warning few weeks ago but I wasn't prepared to identify the bad exit. I set SafeLogging to 0 and I will enable debugging via SIGUSR2 next time this happens. Can someone confirm whether it's a good way of identifying bad exits?
-- Alex _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Wed, Aug 9, 2017 at 4:08 PM, Alexander Nasonov alnsn@yandex.ru wrote:
me@eugenemolotov.ru wrote:
After that check from which ip it was logged in. This probably would be ip of the exit node.
What if they "bridge" mitm-ed traffic to a different host?
I saw a similar ssh warning few weeks ago but I wasn't prepared to identify the bad exit. I set SafeLogging to 0 and I will enable debugging via SIGUSR2 next time this happens. Can someone confirm whether it's a good way of identifying bad exits?
This lack of having easy access to even a short term (3 hour / 10k connections) in memory simple log buffer, that doesn't write to disk or have other log junk to filter out, of what exits users were using before they later happened to notice something wrong, or before the exit changes out from under them for reasons, thus ending their diagnosis, is a *constant* problem users mention on these lists.
You should reopen and lend your support / work this ticket...
# Combine setevents circ and stream https://trac.torproject.org/projects/tor/ticket/11179
tor-relays@lists.torproject.org
-
Alexander Nasonov -
Chad MILLER -
grarpamp -
me＠eugenemolotov.ru -
Roman Mamedov