[tor-talk] A hackish, lame, gnupg backed, volatile way of making hidden service de-anonymisation harder

[x9p]

A hackish, lame, gnupg backed, volatile way of making hidden service de-anonymisation harder

I think today the main problems with Hidden Services are:

-Actors setting up high bandwith relays/guards HS directories and collecting descriptors
-HS vanity name needs to be popular, so users can identify it and come back
-Positioning attack via bruteforce

I believe almost all problems are expected to be addressed with next-gen HS

While waiting for that, we can take some simple steps and take the game to the next level of
cat-and-mouse, which will cause some trouble to snoopers and wanna-be snoopers:

I believe:

-GnuPG is your friend
-Offshore VPS are quite cheap nowadays
-Try to avoid most-know cloud providers for "market entry" servers - Azure, Google, AWS, OVH
-Security-focused Linux and BSD are nice
-Dont be too much paranoid :P

Idea:

-Choose a control server
-Setup 3 "market entry" servers as test on AWS
-Cron job on "market entry" servers rebooting machine every X hours - I know its good to
avoid AWS, but the always changing IP address from AWS instances here are being used in your
favor

Control server (no need to stay online all the time):

1)Access marketplace backend server via SSH, using keys for auth, preferably SSH via HS
 -Generate new HS onion URL every X hours
 -Sign it with GnuPG key

2)Choose one "market entry" server
 -Setup vanity HS private key in a "market entry" server and reload tor
 -Remove vanity HS private from old "market entry" server and reload tor
 -Setup an 302 redirect under nginx/apache/lighthttpd with new HS onion URL generated at 1)
into "market entry" server, put 30 seconds delay, message signed with private key so users
can check wheter redirect is legit or not
 -Expect "market entry" servers to be found, so make them short-lived and rotate between
different providers

cheers.

--
x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE