Correct, it would be prudent to avoid using port 80 over Tor for anything personally identifiable. http://motherboard.vice.com/read/court-docs-show-a-university-helped-fbi-bus...
On 11/11/2015 07:59 PM, Ryan Carboni wrote:
[Mirimir wrote]
You neglected to identify my response! Anyway, CMU's attack did manage to compromise some onion services, most notably SR2.[0] And I'm not impressed with the Tor Project's performance. They apparently ignored the CMU attack for five months. Maybe they got blindsided by a zero day vulnerability. Or maybe they just weren't paying enough attention. But the SR2 connection came up in a comment, and there's no mea culpa for the delay, just blame on CMU. It's stuff like this that fuels conspiracy theories about Tor and the US military. Also, your comment about port 80 makes no sense in this context. The CMU attack deanonymized onion services, not users. And port 80 with onion services is secure. It's non-encrypted traffic through exit nodes that's insecure. There's no exit node when using onion services. [0] https://blog.torproject.org/blog/did-fbi-pay-university-attack-tor-users
On Wed, 11 Nov 2015 20:54:21 -0700 Mirimir <mirimir@riseup.net> wrote:
Well, you are not alone. "Recently research had come that shed some light on vulnerabilities in Tor Hidden Services protocol which could help to deanonymize server locations. Most of the new and previously known methods do require substantial resources to be executed, but the new research shows that the amount of resources could be much lower than expected, and in our case we do believe we have interested parties who possess such resources. We have a solution in the works which will require big changes into our software stack which we believe will mitigate such problems, but unfortunately it will take time to implement. Additionally, we have recently been discovering suspicious activity around our servers which led us to believe that some of the attacks described in the research could be going on and we decided to move servers once again, however this is only a temporary solution. At this point, while we don't have a solution ready it would be unsafe to keep our users using the service, since they would be in jeopardy. Thus, and to our great sadness we have to take the market offline for a while, until we can develop a better solution. This is the best course of action for everyone involved. In the mean time we shall do our best to clear all outstanding orders and we ask all of you users who have money on their accounts, withdraw them as soon as possible, because we don't want to be responsible for it during the time when the market will be offline. During this time, there might be some delays in payouts, since many people are expected to withdraw money at the same time, but we intend to resolve any such issues in the end. But we advice you to use only destination bitcoin addresses that do not expire when you send money out from Agora, as the payments to them might get delayed. While the market is offline, do not send any bitcoin to any of your deposit addresses on Agora. We do not gurantee the safety of any funds sent there. Vendors, we strongly advice you to abort any orders that haven't been sent out or processed yet, as we cannot gurantee what will happen with the orders in resolution. We shall try to resolve it on a case-by-case basis, but there might not be time to wait for orders that require long shipping times. We are going to handle the situation with the vendor bonds soon, we need some time to make sure that noone uses this as an opportunity to start scamming wildly. All of the market data will be kept intact and be available upon return, including all of the user history and profile data. Since our PGP key is nearing expiration date, here is a new PGP key which could be used to check authenticity of our messages in the future. ------------- https://www.reddit.com/r/AgMarketplace/comments/3idznd/agora_to_pause_operat...
On 11/11/15, Mirimir <mirimir@riseup.net> wrote:
this was a very subtle attack in circuit behavior! additional debugging / logging had to be added to be able to track down what was going on, and even then it was a challenge to determine the attack technique. how would you have spotted it?
On 11/11/2015 09:53 PM, coderman wrote:
Yes, it was subtle. But it was also, as I understand it, pointless except as an attack. And it was new behavior, right? But still, it wasn't fair to say "ignored". They just didn't see it.
Right. And they apparently didn't start looking until the Black Hat talk was announced. I did note that they might have been blindsided by a zero day vulnerability.
how would you have spotted it?
I'm not technical enough to answer that. But generally, I think that they ought to put more effort into monitoring. Especially for new relays. Look for anything unusual.
On 11/12/15, Mirimir <mirimir@riseup.net> wrote:
you would not believe the kinds of fucked up clients and relays that participate in the Tor network! even the friendly implementations in Java or Rust have at times failed in ways that look like an attack. i don't think people appreciate the scale, complexity, and novelty of activity in the Tor ecosystem.
But still, it wasn't fair to say "ignored". They just didn't see it.
on this we concur :)
... I did note that they might have been blindsided by a zero day vulnerability.
0day happens! response is important, and Tor has always responded with urgency and transparency in these situations.
this is indeed a challenge! not just for circuit behavior in general, but also bad exit checking (which is usually bad upstream) and suspicious cliques of relays. proposals and patches welcome :) best regards,
participants (5)
-
coderman -
grarpamp -
Juan -
Mirimir -
Ryan Carboni