April 2020 - tor-onions - lists.torproject.org

Onion Service Monitoring
by shadow 16 Aug '21

16 Aug '21

Dear fellow Onion Service operators, I'm curios how you monitor the availability of your onion services? I implemented a solution with icinga2 check commands. It basically queries the onion service via torsocks and check_tcp command [1]. > > object CheckCommand "check_tor_onion" { > command = [ "torsocks", PluginDir + "/check_tcp" ] > timeout = 6m > arguments = { > "-H" = "$hostname$" > "-p" = "$port$" > "-t" = "$timeout$" > } > } This solution is kind of flaky and produces a lot of mail noise, even if I run it with large timeout value (360s), check attempts and retry intervals. Recently I came across the tool called hsprober [2], which looks like a more compelling option. though it requires a prometheus setup. Since it is a network, where connections constantly looses connections, I would like to know how you treat this flakyness. Regardless of which software stack you use, I'm interested in your concept for monitoring your onion services from the outside (user side) and from the inside (server side). And also which tools do you use. Thank you for any answers and opinions. Have a happy new year. shadow [1] - https://www.monitoring-plugins.org/doc/man/check_tcp.html [2] - https://git.autistici.org/ale/hsprober -- best regards | viele Gruesse, shadow(a)systemli.org receive my key: gpg --keyserver zimmermann.mayfirst.org --recv-keys 0x5C6B6ED4248C1F32

7 11

Onion self healing / republish
by Péter Szilágyi 21 May '20

21 May '20

Hey all, I'm sorry if this is something obvious, I've searched for a day and couldn't find satisfactory information. Feel free to point me to relevant resources if I missed them. So, I'd like to run Tor in a P2P setting on mobile phones ( https://github.com/coronanet) In general, everything works as expected. My issues are with the fine grained behaviors of the Tor proxy wrt onion addresses and network connectivity. As long as I allow a stable internet connection to Tor, everything's fine. What I wanted to check is how Tor behaves if I start pulling the rug from underneath it in various states. I've tried keeping Tor offline (network disabled), publish an onion into the service and then enable networking afterwards (SETCONF DisableNetwork 0). This also seems to work, when Tor goes online it publishes the onion that was added offline and I can access it (at least sending a HEARTBEAT signal reports "1 v3 INTRODUCE2 cells and attempted to launch 1 rendezvous circuits"). So far so good. Now comes the more interesting test: while networking is enabled and seemingly everything works, I cut off network access at the router level (i.e. simulate a phone losing WiFi signal / turning off data). Similar to my previous test, I've created a new onion in this scenario too, then reenabled WiFI. Unfortunately, whilst my first onion comes back online, the second one is lost in some black hole. My guess is that Tor **thinks** it's online, fails to register it, then some internal state gets messed up. If I try to list the current onions (GETINFO onions/current), both appear. If I try to list some infos about them via `GETINFO hs/service/desc/id/`, both look the same, reporting their own crypto keys. However, only the first one response, the second never gets router, neither noticed by the local Tor instance. At this point I'd be perfectly happy is this weird scenario was "not meant to work by design", as long as Tor could explicitly tell me somehow that "sorry, onion X is dead, sort it out yourself". I'd be even happier if this worked though. Maybe this is a bug that was fixed in a later version? I'm on 0.3.5.10. Thanks, Peter

3 3

brute forcing Onion domains
by niftybunny 26 Apr '20

26 Apr '20

Hi there, quick question. Is there a fundamental time difference between brute forcing V3 to V2 Onion domains or did my 4 lucky feet just stopped working? niftybunny

2 1