[tor-talk] insufficient hidden service performance is potential de-anonymizing DoS [was Re: [tor-dev] yes hello, internet supervillain here]

[coderman <coderman@xxxxxxxxx>]

thanks for the transparency, nachash! i am putting this conversation
on tor-talk, since my replies are more noise and less dev, and the
details seem to be around Tor use and configuration.


On 11/8/14, Fears No One <nachash@xxxxxxxxxxxxx> wrote:
> ... Another regret is that pcaps weren't taken, but we both made
> the mistake of assuming that because the DoS was mitigated that nothing
> that was preserved would be all that important anymore. If there was
> more to give, we would have been released it.

the pcap dumps would have been most useful, as the access logs only
identify state transitions. these types of attacks likely utilized
many concurrent requests (perhaps just sending a few bytes of the
request string at once, bit by bit, until a request is complete)

performance analysis and tuning of internet sytems is difficult, and
even more so in this context!  (and performance in anonymity systems
is easily reversed for de-anonymizing DoS)

Andrea's distribution shows this type of behavior, as i would expect it:
https://people.torproject.org/~andrea/loldoxbin-logs/analysis/length_distribution.txt
e.g. send small bits to keep connection active and not closed by
server side client send timeouts, then around 900-1000 chars call it
good and finalize the request.

this may be application of slowloris type DoS to "encourage" HS
operator to use a vulnerable path, or confirm via side channel. (you
stated your web server bound to localhost, so the obvious ones you
avoided at least :)



> The box was an OpenVZ VPS (Essentially a glorified chroot jail, for
> those who are unfamiliar)), so no, there was no physical hardware from
> my standpoint. Thus, full disk crypto wasn't really an option. From the
> standpoint of someone with root access to a dedi with OpenVZ vms,
> finding hidden services that are hosted by customers is a matter of
> looking for files named private_key anywhere under the /vz folder.

of all the virtualization environments, i dislike OpenVZ the most. i
dislike all virtual hosting, however, so don't assume this is a vote
for Docker ;)

pay the extra for dedi on bare metal!



> Neither of us are rolling in fake internet money like the drug market
> operators (Hint: This should indicate to anyone thinking of asking if we
> ran bitcoind that we didn'), so the other alternatives were to either
> use rooted boxes or flip a coin to decide who gets to host from home.

ok, maybe a dedi not an option if you're that tight for cash... :/



> ...  As was the tradition with doxbin boxes, the registration info
> usually either went back to ... Keith Alexander...

i find this amusing! my only suggestion is that you incorporate his nickname,
 Keith "Cowboy" Alexander



> I don't have an exact time, but by around 13:00 UTC or so on the 6th,
> the box was down. When the Silk Road 2.0 seizure news broke, doxbin was
> already gone. I checked the most current doxbin onion and attempted to
> ssh into the box every couple of hours for around the first 24 hours,
> until a friend pointed out that one of the old doxbin onions was serving
> up the Silk Road 2.0 seizure page. At the time, the main onion was
> serving up some 404 page (Which I expected to eventually point to some
> sort of honeypot, but the pigs really let me down on that one), while
> other onions were unresponsive. This had changed by the next day, when
> all the onions from the doxbin box were pointed to the seizure page. The
> speculation has been that the cops were adding onions one at a time, and
> my personal experience supports that. Police who are dedicated to
> seizing and taking control of hidden services are still struggling with
> managing a torrc file efficiently. Go figure.

yup. hence slappy fights over the HSDir descriptor publishing is going
to be effective for who knows how long...



> There was some downtime on the box maybe a month ago, which I originally
> thought was when it got imaged pre-seizure, once all this drama began. I
> can't look at the access log report numbers and say "This is the date,
> because there's a huge dip in traffic" so I'm going to have to get back
> with you on that. The fact that they were adding onions to the seizure
> box over 24 hours after the takendown might suggest that they for some
> reason didn't image it beforehand, which would be a curious break from
> their habits as laid out in past criminal complaints.

this was an international effort, so perhaps just one hand not talking
to the other, is the only conclusion to be drawn.



> An update: All of the access log reports ever generated for doxbin can
> be now be downloaded from the URLs in my initial e-mail. Other people
> wanted some of them to compare to the DoS log reports, so now they can
> pick their own control group.

thanks for this, while not as useful as PCAPs with headers, it is still useful!



> P.S. Neither of us have been arrested or have even noticed any signs of
> in-person heat (Cleaning vans, new neighbors, etc), which also seems to
> point to the doxbin seizure being half-cocked.

how would you know what covert heat looks like?
*grin*



> Here until I'm in handcuffs,

don't plea out!

P.S. public key?


best regards,
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk