[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #29607 [Core Tor/Tor]: 2019 Q1: Denial of service on v2 and v3 onion service



#29607: 2019 Q1: Denial of service on v2 and v3 onion service
--------------------------+-------------------------------
 Reporter:  pidgin        |          Owner:  pidgin
     Type:  defect        |         Status:  accepted
 Priority:  Immediate     |      Milestone:
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:  Sponsor27-can
--------------------------+-------------------------------

Comment (by asn):

 Replying to [comment:38 HelpDOS]:
 > Replying to [comment:37 asn]:
 > > Replying to [comment:36 HelpDOS]:
 > > > Replying to [comment:35 asn]:
 > > > > Closed #29919 as a duplicate for this one. More info over there.
 > > >
 > > > Hi asn,
 > > >
 > > > Understandable why you closed my ticket, at a point of desperation
 and just hoping someone will take real interest in looking into this.
 Which is why I am able to offer access to a server that is currently being
 attacked. I believe I saw a chat log of you first discussing complex mode
 in 2015 for OnionBalance. Do you have any links for how to enable
 it/configure it? I am going to try it out to see if it is a resolution for
 this, with the theory of introduction points being attacked.
 > > >
 > > > Thank you.
 > >
 > > Hey, I just remembered that complex mode was never implemented for
 onionbalance, because it was harder to implement and we thought there was
 no real use for it.
 > >
 > > I'm not currently interested (or have the time) to get access to a
 server that is under attack.
 > >
 > > I think the most useful thing right now would be to have more logs
 that display the attack. I want debug or info logs that last for 1-2 hours
 of the attack and display the whole Tor lifetime (from startup to
 shutdown). Please sanitize them correctly (make sure that guard names and
 onion names are not visible).
 > >
 > > Same for vanguard logs on debug or info if you use vanguards.
 >
 > I will provide you with any logs I can later today. Could you please
 send a full list of anything that could help in debugging just to make
 sure you have everything relevant? Thank you

 Hm. It would be great if we could have all debug logs from Tor startup to
 Tor shutdown. Please scrub the names of your primary guards and your onion
 address and anything else that might seem pervasive, but please try to not
 destroy the accuracy of the logs (by double-pasting or removing
 surrounding lines).

 Another thing that might be helpful would be to try with a blank
 '''state''' file so that Tor discards any previous circuit timeouts and
 performance measurements etc. (you can find the state file in your data
 directory. please don't delete it, just backup it somewhere else so that
 you can then restore it).

 Furthermore, it would be cool if we knew exactly when Tor tops up to 100%
 CPU. Will it happen immediately? When will it happen? I would like to
 correlate the time with the log lines. But if that's too much to track,
 just do all the rest well and it should be OK.

 Again, I cannot guarantee that such a log file will result in us instantly
 solving the problem, but it might move us forward.

 Cheers.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29607#comment:39>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs