I would think a bridge could be considered a private relay. You can even setup the bridge so it is not broadcast to the bridge authority. In that setup you would be the only person able to give out access to the bridge, so if you wanted you could keep it private to just yourself.
General info on bridges:
No, the HS directory is accessed via Tor. See: https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n549
The nodes running HS directories do form a distributed hash table, though it's not decentralized the same way that Freenet is, since all of the HS directory nodes are listed in the Tor consensus. So the client identifies which HSDir node is ...
From the obfs4proxy README:
The autogenerated obfs4 bridge parameters are placed in
DataDir/pt_state/obfs4_state.json. To ease deployment, the client side
bridge line is written to DataDir/pt_state/obfs4_bridgeline.txt.
If a user connects to the clearnet webservice with Tor - then the webserver sees the exit node used by the user.
If the user connects to the webservice through the .onion domain - the webserver sees the ip as 127.0.0.1 (localhost), and have no idea where the traffic comes from.
The main difference is that if you connect through the onion domain everything ...
It's not enabled by default because it would block a significant fraction of the Internet for users. Blocking HTTP-only traffic will likely come in the future once Tor Browser is using a version of Firefox with HTTPS-only mode, and once the developers feel they can do it while minimizing the usability impact (for example providing documentation to explain ...
By definition bridge relays are Tor relays that aren't listed in the main Tor directory. So if you set:
this will cause your relay to not publish anywhere. This could be
useful for private bridges.
If you set:
your relay descriptor will be publised to the bridge ...
It is not possible to run a private Tor relay, but it is possible to run a hidden service with 1-hop circuits and connect to it with a Tor client running in tor2web mode. However, you need to recompile tor on both machines to change default hidden service circuit hop count (on the server) and enable tor2web mode (on the client).
Running a bridge seems ...
Also, why there is a UDP socket "listening" on my machines
I think it's DNS (you can add DNSPort 5353 option in torrc and you will see).
The problem is, i have unexpected and yet unexplained opened socket on my VM's.
Look at your torrc for the following option "ORPort". It's external port for incoming tor connections. (in your torrc it uses 5000 port if ...
To my knowledge, there is currently no way to avoid that your key, at least for a short time, is on your server in cleartext.
However, the next generation onion services (V3) will allow you to do that once ticket #18098 (offline keys) has been implemented. Beware that the addresses differ from V2 addresses and you'll have to create a new onion address.
There are a few things going wrong here.
You're not reversing the IP octets, so if this ever was "working" it only looked like it was.
You're using X-Forwarded-For which can be defined, arbirarily, by the client so this isn't trustworthy. A user can edit this header to trick your script into thinking that either they are using Tor when they're not or they'...
Somehow it matters, but not fatal. Here are your two cases for a start:
You have connected to Tor after using an authorized page. If your actions you do perform through Tor can be linked with your profile - it's a guess-hint, that it can be you, but not a proof: tor's traffic is 3-times encrypted, at least. If you're using something like Facebook that does ...
Technically this kind of thing can be done through a pluggable transport.
I'm not aware of anyone actually having done this specifically. It probably wouldn't work very well, a curious observer would notice that you always send short messages and receive messages in orders of magnitude larger in response, which may not (I've no studies to back this up) be ...
You're missing an actual versions of Tor in your system, it's all in your error logs. You have basically/mostly two types of error:
binary not found - you're missing tor-gencert in message
Cannot find tor-gencert binary 'tor-gencert'. Use CHUTNEY_TOR_GENCERT environment variable to set the path, or put the binary into $PATH.
Tor binary is old/improper ...
I had the same issue trying use socat to run an application through the Tor socks proxy on Tails. I was trying this:
# socat TCP-LISTEN:1234 SOCKS4A:127.0.0.1:remoteip:5678,socksport=9050 &
$ telnet remoteip 5678
telnet: Unable to connect to remote host: Connection refused
I had a grope around iptables and realised that Tails restricts ...
You are running a relay. (If this was your intention, then thank you!)
Running a relay is not private / anonymous, it is public. Your IP needs to be public, so that other relays can connect to you to build circuits. So your Tor is now part of the Tor network.
Running a relay is not to keep yourself anonymous. It is to help others stay anonymous.
If this ...
It's probably in your HTTP_ACCEPT headers. See
If you can see your language there, so can other sites you visit. Mine says:
HTTP_ACCEPT: Headers text/html, */* gzip, deflate en-US,en;q=0.5
As already commented, there are only three relays a normal circuit goes through. The exit relay obviously knows it is the exit - because it is asked to make a connection to the outside world. For middle and entry nodes, it is not as clear-cut, but still pretty easy to figure out in most cases: If the connection comes from a known Tor relay IP address, most ...
If you install Tor browser correctly, or use Tails, the likelihood that you employer will identify you by technical means is very small. Your IP address will be masked and will show in your employer's data-logs as being the IP of the Tor exit-node.
So the real question then becomes one of whether you will be identifiable on the basis of the content of what ...