tor-dev

tor-dev@lists.torproject.org

3581 discussions

shipping with fallbackdir sources
by l.m 22 May '15

22 May '15

Hi, a couple questions about fallback directories. On 4/17/15, Peter Palfrader wrote: > We want them to have been around and using their current key, address, > and port for a while now (120 days), and have been running, a guard, and > a v2 directory mirror for most of that time. In the script (and proposal 206) a candidate for fallback uses the orport. When is the http directory connection used? Is it just for backwards compatibility? Does the directory address being different not matter? A candidate can only be or-address+orport? If the document is signed why is bootstrapping using the or-address+or-port for candidates a key consideration? Aren't the clients going to switch to guards and tunneled dir-connections anyway? (Unless configured otherwise) In a worst-case the client would still use bridges if tor is blocked--and it doesn't look like the fallback-dir are being considered for this case anyway. Is there more documentation somewhere? Thank-you --leeroy

1 0

Quantifying the similarity between Tor relays
by Philipp Winter 22 May '15

22 May '15

It is often helpful to determine the similarity between relay descriptors. For example, to detect Sybil attacks, or to find partners in crime once we found a malicious relay. I recently added code to sybilhunter that can automate this task. Now to the underlying theory. The algorithm makes use of a vantage point tree (vp-tree), which enables O(log n) search for nearest neighbours. We then take a file as input -- for example a consensus document -- and add every relay to the vp-tree. For node comparison, vp-trees require a distance metric in the mathematical sense, i.e., the metric has to satisfy the triangle inequality. For now, I use the Levenshtein distance. It takes as input two strings and returns the number of character edit operations (replace, insert, remove) that are necessary to turn descriptor A into descriptor B. While easy to understand and use, the Levenshtein distance cannot easily incorporate our domain-specific knowledge. I hope to find something more suitable. Before comparing relay descriptor, I preprocess them. For network status documents, I consider nickname, ports, publication time, flags, version, and bandwidth. I believe this is a good start, but there is much room for improvement and feedback is very welcome. Now here's how you can give it a shot. The commands below find the 10 closest relays to the relay we run at Karlstad University: $ go get git.torproject.org/user/phw/sybilhunter.git $ wget https://www.nymity.ch/~phw/sample-consensus -O /tmp/consensus $ sybilhunter -data /tmp/consensus -neighbours 10 -rootrelay 9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645 On my laptop, it takes approximately 10 seconds to generate the vp-tree. The output then consists of 10 blocks that represent the most similar relay descriptors. The first two lines of each block show the input to the Levenshtein distance. The third line shows the distance and a link to the relay's Atlas page. Cheers, Philipp

1 0

[PATCH] Defences against the recent hidden service DoS attacks
by George Kadianakis 21 May '15

21 May '15

Hello, we recently received more reports of Denial of Service attacks on hidden services. You can find our ticket here: https://trac.torproject.org/projects/tor/ticket/16052 After some debugging, we found the attack vector and identified a few ways to fix or mitigate it. In this attack, the adversary forces a hidden service to create thousands of connections to its underlying application (e.g. the webserver), which overwhelms both Tor and the underlying application. It's worth noting that Tor is a small network, and even simple DoS attacks can be quite effective against it. Consider that there are botnets out there with more bandwidth than the whole Tor network. Hence, completely solving DoS attacks on Tor is still an open problem; a few long-term defense ideas were stated on the trac ticket. In any case, we have prepared an experimental short-term fix for this vulnerability that hidden service operators can deploy. It seems to mitigate the attack in our lab tests, so maybe it helps others too. The fix, allows the hidden service operator to ignore hidden service circuits that try to open tons of connections. This is possible since normal clients will only open a few such connections, whereas the attacker was opening like 5000 connections per circuit. Here are some instructions for the short-term fix: == Instructions == Our patch is not in an official Tor release yet, so you will need to use an unofficial git branch: https://trac.torproject.org/projects/tor/ticket/16052#comment:18 First, use one of the provided branches or apply the commits directly to your tor, and recompile your tor. You need to do this. The instructions below *won't* work with stock tor. Next, an operator who wants to deploy this experimental fix, should first figure out how many simultaneous TCP connections a normal client would establish. For example, an IRC server would probably not need more than 1 simultaneous connection per user. A web server, depending on the use, might need something between 6 to 12 (?) simultaneous connections. To proceed, as an example, let's say that a client of your hidden service can work fine with 20 simultaneous TCP connections. Then add the following to your torrc, as part of the per-hidden service configuration: HiddenServiceMaxStreams 20 and start up your new Tor. See if that helps out for you. You might still get 100% CPU when under attack, but other clients should work normally. If that doesn't stop the attack, there is a more aggressive solution that might work. In your torrc also add the following line HiddenServiceMaxStreamsCloseCircuit 1 That will make your hidden service *kill* the attacker's circuit, which will reduce CPU load even more. However, if you have picked a small max streams number, it might also kill normal users' connections. So be careful! Also, please don't set max streams to a tiny value while this is enabled; forcing the attacker to build tons of circuits to you is not good for your HS or for the network. ==== In any case, let us know if this works for you, by sending an email to this list, or commenting on the trac ticket. If it works for people, we might incorporate to a Tor release soon.

2 1

Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"
by George Kadianakis 21 May '15

21 May '15

Hello, I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypte… Feedback would be greatly appreciated. Here are some specific points that I would like help with: - Should we require a specially compiled version of Tor to enable this feature? Like we do for tor2web mode? In this proposal, I didn't require any special compilation flags. I don't have strong opinions here. - We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one that the NRL people suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services - We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names. Here goes proposal: ---- Filename: 244-direct-services.txt Title: Direct Onion Services: Fast-but-not-hidden services Author: Roger Dingledine, George Kadianakis Created: 2011-01-12 Status: Draft 1. Motivation Hidden services can cover multiple use cases and threat models. They offer server-side anonymity by default because that's the most common use case, but there also hidden service users who don't really need service-side anonymity. This proposal aims to satisfy those users by introducing an optional opt-in feature that *sacrifices server-side anonymity* *for better performance*. Client-side anonymity will still be preserved as normal. Here are some use cases that this idea addresses: 1) Indymedia wants to run an exit enclave that provides end-to-end authentication and encryption. They tried running an exit relay that just exits to themselves (#800) but * it handles lots of other traffic too since it's a relay * exit enclaves don't actually work consistently, because the first connection from the user doesn't realize it should use the exit enclave. 2) Wikileaks uses Tor hidden services not to hide their service, but because the hidden service address provides a type of usability we didn't think much about: unlike a more normal address, a Tor hidden service address either works (meaning you get your end-to-end authentication and encryption) or it fails hard. With a hidden service address there's no way a user could accidentally submit their documents to Wikileaks without using Tor, but with normal Tor it's possible. 3) The Freenode IRC network wants to provide end-to-end encryption and authentication to its users, a) to handle the fact that the IRC protocol doesn't really provide much of that by default, and b) to funnel all their Tor users into a single location so they can handle the anonymous users better. They don't mind the fact that their service is hidden, but they'd rather have better performance for their users given the choice. As a side-effect, by optimizing for performance in this feature, it allows us to lean more heavily towards security decisions for regular onion services. 2. Design We suggest the following changes to be implemented: i. Add a way in the torrc file to specify that this service wants to be an encrypted service rather than a hidden service. [TORRC] ii. An encrypted service SHOULD establish 1-hop circuits to its introduction points. [ONEHOP] iii. An encrypted service SHOULD establish 1-hop circuits to rendezvous points [ONEHOP]. iv. An encrypted service MAY NOT use static guard nodes [NOGUARDS]. More information about these steps can be found in the next section. 3. Specification 3.1. Torrc configuration parameter [TORRC] To enable this optional feature, we introduce the boolean DangerousDirectOnionService torrc option. The option MUST be *disabled by default*. Because of the grave consequences of misconfiguration here, we have prepended the torrc option with 'Dangerous'. Furthermore, Tor MUST issue a startup warning message to operators of the hidden service if this feature is enabled. 3.2. One-hop circuits [ONEHOP] When in this mode, the onion service establishes 1-hop circuits to introduction and rendezvous points. The onion service SHOULD also ignore cannibalizable 3-hop circuits when creating such circuits. This looks like this for the rendezvous point case: |direct onion service| -> RP <- client middle <- client guard <- |client| This change allows greater speeds when establishing a hidden service circuit and reduces round-trip times. As a side-effect, busy onion services with this feature cause less damage to the rest of the network, since their traffic gets passed around less. 3.3. Disable guard nodes [NOGUARDS] Entry guards are a security measure against Sybil attacks. Unfortunately, they also act as the bottleneck of busy hidden services and overload those Tor relays. This proposal suggests disabling the entry guard feature entirely when this mode is enabled. This allows the hidden service to split its traffic out to multiple relays on the network. 4. Security implications There's a possible second-order effect here since both encrypted services and hidden services will have foo.onion addresses and it's not clear based on the address whether the service will be hidden -- if *some* .onion addresses are easy to track down, are we encouraging adversaries to attack all rendezvous points just in case? 5. Future Here are some thoughts on things we could look in the future to further optimize performance when this mode is enabled: - We should look whether we can optimize further the preemptive circuits that Tor makes as a hidden service. - We could also make hidden services determine the number of introduction points based on their popularity, to allow greater load balancing. This has the potential for leaking the popularity of hidden services (#4862), but maybe this is not a concern when this mode is enabled. - For this mode, we could look into alternative designs where a rendezvous step is not needed, and the traffic gets routed through the introduction points (as in Valet nodes [0]). [0]: http://freehaven.net/anonbib/#valet:pet2006

12 26

Namecoin .onion to .bit linking
by Jeremy Rand 21 May '15

21 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Tor-Dev, One of the criticisms of Namecoin which seems to be raised sometimes is that the current domain namespace spec doesn't have a method for a .bit domain owner to prove that they are in control of a .onion. (This is also an issue for .bit domains that point to .i2p.) I'm interested in improving this situation, and am looking for feedback. First off, I'm curious what the various use cases are for this. The main use case I'm aware of is if a user is aware of a .onion domain already, and is trying to find a human-memorable way to access it. (As far as I can tell, the reverse is not a use case, because if you already trust the .bit domain by name but don't know what .onion you're looking for, presumably Namecoin already does what you want.) Is this correct? Am I missing any other significant use cases? Second, I'm looking for feedback on my rough approach. The approach I'm looking at right now is to have a Namecoin namespace for .onion backlinks to .bit domains, which is separate from the Namecoin namespace for .bit domains. The backlink namespace would have a name field whose prefix is the .onion domain. We can't prevent a squatter from registering an exact match of the .onion in Namecoin, but by using a prefix and checking the signature on all matches, we can avoid the impact of squatters. (The cost of obtaining new names would be a deterrent for someone trying to flood a .onion prefix with invalid backlinks as a DoS.) The value field would contain a signature of the domain name being pointed to, signed by the .onion key. The .onion key could also sign revocations of an endorsement of a .bit domain; these would also be in that namespace. Is this generally a good approach? I'm aware that cross-protocol attacks need to be carefully considered when signing things with a .onion key -- do you have suggestions on how I can sign a short JSON string of the rough form {"name": "d/domain", "rev": 0} (which corresponds to endorsing domain.bit, and not being a revocation of that .bit domain) in a way that won't open up attacks on the .onion key's normal protocol usage? I'll write up a more formal spec after feedback is received, just to make sure I'm not missing some important details. Cheers, - -Jeremy Rand https://namecoin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVW0v7AAoJEAHN/EbZ1y06C+AP/3RxO99cPoBQ6eRcY9cefqlC HGnfUtxfAa7Ao2Ea2ZatHjA36ordtz6vo9UpJKDXXLPuQFMnsW/Xf6m2ePCKPssG uivWnAqoZ/zFaJFXf6RqgADrbUei7jW75DFmJfwhPka3kh76mF/B3mMIRx9bCOIq r8XcKRlmbFv55j0srg2Z6SBpq8aMumxGjStjyzsW8L6bVtBvz4DwN5rAZG958Hm3 ji7b6r+v05s4dIbJ6ZAqerOVmy6PA+sAZ0cqwzCBBttdIoVzGiuc9S6aAn8+XjWa ycx7wUi3YM27Kyor8N2+pYDgECmMYEC9QBKN6XwtsW6Lwz9UCNaZ4BQR5JWIxwLg FTZ1uV/E7o3cKdiPzlCkzoQetifom8la6ezPOpr4XhVuzLWqHJBm4eA+qEwEPSFC DA4k/HEgJKNUZGFWuXpIyEAl3Nvyy3cxTYyrzzMmbvBJnzMGM18Sa+D9N78ih3Sw GgXIET336wnvd+HqcVT85io7Ee3Wj+05IOyH4mhV06AXJuP1RvFAKJk6d1i5lOKC Sr2GrJNnP8zP1uq57XQxpKg7fkVqBMzjFY9JJ6HIkffLsGzLpZ8CUSU2+8tPGeDt T3MAT3GKqXCIjIiQy39Ban27ixeJyxzq8dN3T2HvnUNna0M9v3VhxQjeauNzjHTk 9ekMPDGGT7X9TmLOvSXq =WbCd -----END PGP SIGNATURE-----

3 4

Re: [tor-dev] The Onion Name System (OnioNS)
by OnioNS Dev 20 May '15

20 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/19/2015 03:20 AM, tor-dev-request(a)lists.torproject.org wrote: > Subject: > Re: [tor-dev] The Onion Name System (OnioNS) > From: > Christian Grothoff <grothoff(a)gnunet.org> > Date: > 05/19/2015 03:24 AM > > To: > tor-dev(a)lists.torproject.org > > > Please write an IETF draft asking for ".tor" to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's ".onion" draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^. I will put that on the to-do list. > Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). Thanks, I'll make those corrections. Good to hear from someone who is part of that system. > I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names. My scheme is better than Namecoin in several key ways: 1) No miners. I'm relying on the existing trust of the Tor network and purposely did not create a new network. 2) Minimal networking costs. Namecoin typically requires users to hold the blockchain, and has very little client-side security when users rely on name servers to hold it for them. I require clients to check a set of signatures from Tor routers. Most of the attack vectors for OnioNS also results in a compromise of Tor, which makes the whole thing moot. Hence it makes sense to rely on Tor. The PoW is only for registration, no one else does it. Yes, it is first-come-first-serve, but so is Namecoin. On the Internet DNS, someone with lots of money could buy up domains too (ISPs do this all the time). For well-known hidden services (such as DuckDuckGo) we could mark those names as reserved such that only the owner of that hidden service could register it on OnioNS, and let all other names be first-come-first-serve. I'm thinking of setting the proof-of-work relatively high, say four hours on an i7 or so. The reliance on scrypt and the complex of the domain registration should restrict this to CPUs. > I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys? I only have 12 pages, there wasn't enough space for that protocol. However, I have already created protocols for deleting, transferring, and updating Records. Domain registration uses the same private key as hidden services, so if the key is compromised, both are compromised and the security of the Record is moot. > It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone. I'm considering that all OnioNS data is public. There's no way to hide information in the Pagechain as Mirrors need to verify it. An attacker could also spin up a machine, synchronize with the network, and enumerate them anyway. Clients must also see the domain names in the leaves of the Merkle tree in order to authenticate Records or verify that the domain does not exist by finding two domains that alphabetically span it. I also can't hide the domain names in the Merkle trees via hashes because then I'm mapping unique names to a binary space that may have collisions. It's far easier to just consider the information public. Fortunately, there's no personally-identifiable information in the Pagechain, so there's no advantage in hiding the data. > Why do you limit names to 128 characters, when DNS supports 253? For space reasons. Longer names introduce more storage and networking demands. The smaller choice shouldn't make any practical difference; I have yet to see a domain name on the Internet with a 253-character second-level domain. > With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities and their opinions, not majorities. (see also http://grothoff.org/christian/fps2013wachs.pdf). Thus, you might want to make it clearer in your paper that you 'square' Zooko's triangle under exactly the same conditions as Namecoin: a weaker adversary model / definition of 'secure'. I think you may misunderstand. Computational power (PoW) here has nothing to do with Zooko's Triangle. With Namecoin, the network is assumed to have more CPU power than adversaries and thus they can achieve all three properties. Here, PoW is only used to increase the difficulty of claiming a domain name, and I get the uniqueness property because I assume that Tor routers are generally honest. This is a safe assumption as if Tor routers weren't honest, Tor circuits would not provide privacy and again the whole system breaks and becomes moot. So, I assume that Tor routers follow the rules and reject duplicate domain names, therefore the network as a whole prevents collisions. An attacker could win here by Sybil attack by spinning up many new Tor routers and gaining control of the Quorum by placing the statistics in their favor. My analysis shows that this is extremely unlikely for L_Q >= 127. > All that being said, I'm not at all against this: We should have MANY ways (protocols!) to assign names, some more usable, some more secure, especially as the current dominant method is just broken (DNS). Glad to have your support. I agree that the Internet DNS is broken. It was never designed with security in mind in the first place; there was no need to because originally everyone knew each other. :) > So maybe Tor can plan to incorporate ".tor", ".bit" (namecoin), ".onion" and ".gnu". After all, each solution has interesting advantages and drawbacks. (The problem then only becomes educating the user about those.) Regardless, good luck with ".gnu" and I look forward to the resulting discussions on dnsop (IETF mailinglist), where you really should launch a discussion on this as well. Yawning mentioned this. It's easy enough to create a spec that defines the protocol for handling other pseudo-TLDs. Currently Tor writes "*.tor" to a named pipe, reads "*.onion", and finishes the lookup. It's easy to use that protocol for any alternative DNS. It's outside Tor's scope to care how the *.tor -> *.onion map is accomplished. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVW26lAAoJEK2XNk/CC+yA+1MH/3HNANFFzhCs567B8XkcHu0M VijH8dD6f+ClxuxVFmjKb5c9jlgK5vW9E+LsFiUFbT3vHdjZxh4nH4zNv1FnVIxc RnkNvuhXGYpDCSRFNtvqa1ZPwOj3ENBvB8++wB/M2DM3KN4B6dKXdHNgjfMDNfji L62o23ApQaKOu8vi0wr9VNLTCbji9LS0GerR5G7mUMAUo194WjBGhNwhBQknCeze RACjHnRjfqDWSyszgI7e0xKNK3rGOzQWIPwlScqnl1LEh6tWaxMZDmzN+FHr2QbG C5Sb1fDywKeVCQdBSAjAS++WvzvYNbiFExaJ9ucVWMPMdjrxjDzpHrVM8P/xWaY= =6kyi -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] Namecoin .onion to .bit linking
by OnioNS Dev 19 May '15

19 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > On 05/19/2015 10:02 AM, Daniel Martí wrote: >> I'm not familiar with Namecoin, but I thought I'd just point out >> that someone will be working on OnioNS, the onion name system, as >> part of the SoP in Tor. The person who will be working on it just >> sent an e-mail to this very list yesterday. >> >> You two seem to be after the same "human-readable way to access >> .onion domain names" target as you yourself described, so there >> might be room for collaboration. > I'm aware of OnioNS, but haven't yet had time to thoroughly read the > proposal. It's certainly on my to-do list, if nothing else for > cross-pollination of ideas. > > - -Jeremy Yes, I'm here. Last year I explored Namecoin as a possible alternative DNS for Tor hidden services. I spent some time over it, but I also ran into the same problems previously mentioned above: how to link HS RSA keys to Namecoin ECDSA keys. I came up with two solutions: sign the Namecoin key with the HS key and embed that signature in the blockchain, or introduce a new blockchain that relied on the same cryptography as hidden services (RSA, Ed25519, ECDSA, etc, as long as they matched). As I mentioned in the ACM paper, it's non-trivial to build this correlation and I came to the conclusion that solutions would look more like a hack than an elegant solution. Moreover, even if the correlation could be built, it's impractical to require clients to download the whole blockchain before use, so you still have to address the issue of preventing name servers from lying. I hope you can see that it's a difficult problem. I think Namecoin could use a solution if you come up with one, and I would be interested in hearing about it. I came to the conclusion that Namecoin would not work and wrote something different. Namecoin does many things well and I took those good design ideas, but I also changed the setup to solve many of its weaknesses. Namecoin, GNS, and OnioNS are good alternative DNSs, each with their own approach. Let's see if we can work together here, we might be able to help one another. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVW52lAAoJEK2XNk/CC+yAUtQH/1a9zZQK2XYsQofGt+qtrAA0 MZmBHMTC+lBLcpq1ZSIYCD+vJ8DEO1Aoqrzfj7RVsS5T1dfXZ5B4D+u2XB+Obg1+ uW86/cWQ3S2UgFRg5Mg0+6C+3T7sIwBya3foXg0/dETh4R9J2QzSG7iobsvjuivr TEUh7iGl+9zBDHad3s5ZZRBms9ZHk4fQy1ckFx6h9bvh5ybzaZZKc8bAYdRF1yTi RQw4MmtoJ4e2MZf7Ze9qVn863KOLQQzOlw0ddQ4tCLpHfBwr+l+lK5waGflVYLjU C2RVt9QUS83PgDXY3sKp+kIlfqp0Oupf7ZFqq6xAHWIHORvcr8vERtFadWLiQVw= =vl1G -----END PGP SIGNATURE-----

2 1

The Onion Name System (OnioNS)
by OnioNS Dev 19 May '15

19 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone, I'm the one behind the Onion Name System (OnioNS), a Tor-powered distributed DNS for Tor hidden services. It's been several weeks since my project was selected for the SoP program, and I've finally got around to posting here about it. My project aims to solve the major usability issue that has been with hidden services from the beginning: their un-memorable addresses. I'd like to discuss a bit about how it works, where my project is described, and where I am with the implementation. Under OnioNS, a hidden service operator can anonymously claim a meaningful domain name for their hidden service (a map between the .tor and .onion pseudo-TLDs) and then transmit it over a Tor circuit to an OnioNS server, which is also a Tor router. The claim propagates across the Tor network. Later, a user may type a .tor domain name into the Tor Browser. My software intercepts this domain, performs a lookup over a Tor circuit to an OnioNS node, and learns the corresponding .onion address. Then it tells the Tor client this, which contacts the HS in the normal way. The result of this process is that a hidden service loads transparently in the Tor browser under a meaningful name. I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor -> onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum. Clients don't need a copy of the Pagechain to use the DNS, but rather they can just rely on their existing trust of the Tor network (including the Quorum and name servers) and verify their signatures on data structures. Also unlike a blockchain, my Pagechain has a finite length: the oldest Page will eventually drop off, which forces domains to be renewed periodically. I have also introduced mechanisms that 1) allows clients to authenticate the domain name to the hidden service, 2) allow clients to authenticate a denial-of-existence claim from a name server, and 3) prevent name servers from forging .tor -> .onion associations. These vulnerabilities are still generally open on the Internet DNS. I have also tried to minimize networking costs, since Tor circuits are slow. To reduce CPU and network requirements, I want Tor routers to have Ed25519 keys. Let this project add additional pressure on that item on the to-do list. Recommended readings: http://onions55e7yam27n.onion -- the official hidden service for this project, but a work in progress. https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf -- the ACM paper pending peer review I no longer recommending reading my original thesis, please use the above links instead. My prototype can be found here: https://github.com/Jesse-V/OnioNS It's a bit unstable, but it does work once and sometimes twice. Please contact me (kernelcorn on IRC) before running the prototype, I need to ensure that the name server is up before you can try it out. You can also send me registrations over IRC and I can add them in. I am asking for help with the client-side functionality. I'm currently doing the *.tor interception and lookup resume in connection_edge.c but the software frequently crashes with this approach, (I've learned why) and I'd like to migrate it to Stem for now. I need to intercept .tor domains, pause the lookup (letting the Tor Browser spin), send the hostname over a named pipe or TCP socket, read back a .onion address, then tell Tor to resume the lookup under the .onion address. This way, the HS loads under a .tor domain. All other lookups should load as normal. I've never used Stem before but I understand using it will be a lot easier than hacking Tor. I have Stem up and running now. Any recommendations for what I'm trying to do here? - -- Jesse V. (kernelcorn) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVWnpiAAoJEK2XNk/CC+yA0MsH/Ahg3V1U+bIRqawmVu5Ju85C gAqVqJx3pYsJPDHpmZU2OGICGIAWVMS0d8wA39H42MBJG3AP/1PGevlB8tK+/i5K t/o3vLTt9WpuxL3Lf2+VihlDTFnUSQz+02pMyghwjS3ANoutoLb2wMB/EeSn74FS ozLjEkO7fbyEx1Qzp4xDHKNjfRBmkn2k83O9YhEPZ6d6VYFHrCfsygd6XvHpuPzT XLu3OyamFeT5BjZgkX2gge+zG9UUOmDLC2aCQa83gHxcty3Sdh5aZ33oVfx9bROU +AaD2yAbLNaq/mEmp2qaAOnsQCzBTrRJ5CX9jyLvCOVYi3SZtl/4Ju/oomWqHl0= =TvQm -----END PGP SIGNATURE-----

3 2

FTBFS for ooniprobe on Fedora 21
by Jacek Wielemborek 18 May '15

18 May '15

Hello, Below is the log. Am I missing some package or something? [1:07:53][~][1] $ sudo pip install ooniprobe zsh: correct 'pip' to '.pip' [nyae]? n Downloading/unpacking ooniprobe Downloading ooniprobe-1.2.2.tar.gz (13.4MB): 13.4MB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/ooniprobe/setup.py) egg_info for package ooniprobe /usr/share/GeoIP/GeoIPASNum.dat already exists. Skipping. /usr/share/GeoIP/GeoIP.dat already exists. Skipping. /usr/share/GeoIP/GeoLiteCity.dat already exists. Skipping. warning: no files found matching 'data/inputs/' Requirement already satisfied (use --upgrade to upgrade): PyYAML>=3.10 in /usr/lib64/python2.7/site-packages (from ooniprobe) Requirement already satisfied (use --upgrade to upgrade): Twisted>=12.2.0 in /usr/lib64/python2.7/site-packages (from ooniprobe) Downloading/unpacking ipaddr>=2.1.10 (from ooniprobe) Downloading ipaddr-2.1.11.tar.gz Running setup.py (path:/tmp/pip-build-YH9MXT/ipaddr/setup.py) egg_info for package ipaddr Requirement already satisfied (use --upgrade to upgrade): pyOpenSSL>=0.13 in /usr/lib64/python2.7/site-packages (from ooniprobe) Requirement already satisfied (use --upgrade to upgrade): geoip in /usr/lib64/python2.7/site-packages (from ooniprobe) Downloading/unpacking txtorcon>=0.7 (from ooniprobe) Downloading txtorcon-0.11.0-py2-none-any.whl (175kB): 175kB downloaded Downloading/unpacking txsocksx>=0.0.2 (from ooniprobe) Downloading txsocksx-1.13.0.3.tar.gz Running setup.py (path:/tmp/pip-build-YH9MXT/txsocksx/setup.py) egg_info for package txsocksx zip_safe flag not set; analyzing archive contents... Installed /tmp/pip-build-YH9MXT/txsocksx/vcversioner-2.14.0.0-py2.7.egg Downloading/unpacking parsley>=1.1 (from ooniprobe) Downloading Parsley-1.2.tar.gz (275kB): 275kB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/parsley/setup.py) egg_info for package parsley Downloading/unpacking scapy-real>=2.2.0-dev (from ooniprobe) Downloading scapy-real-2.2.0-dev.tar.gz (1.1MB): 1.1MB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/scapy-real/setup.py) egg_info for package scapy-real Downloading/unpacking pypcap>=1.1 (from ooniprobe) Downloading pypcap-1.1.1.tar.gz (44kB): 44kB downloaded Running setup.py (path:/tmp/pip-build-YH9MXT/pypcap/setup.py) egg_info for package pypcap Found pcap headers in /usr/include/pcap/pcap.h Found libraries in /usr/lib64/libpcap.so found pcap_setnonblock found pcap_compile_nopcap function found pcap_file function Downloading/unpacking service-identity (from ooniprobe) Downloading service_identity-14.0.0-py2.py3-none-any.whl Requirement already satisfied (use --upgrade to upgrade): zope.interface>=3.6.1 in /usr/lib64/python2.7/site-packages (from txtorcon>=0.7->ooniprobe) Requirement already satisfied (use --upgrade to upgrade): pyasn1 in /usr/lib/python2.7/site-packages (from service-identity->ooniprobe) Downloading/unpacking pyasn1-modules (from service-identity->ooniprobe) Downloading pyasn1-modules-0.0.5.tar.gz Running setup.py (path:/tmp/pip-build-YH9MXT/pyasn1-modules/setup.py) egg_info for package pyasn1-modules Downloading/unpacking characteristic>=14.0.0 (from service-identity->ooniprobe) Downloading characteristic-14.3.0-py2.py3-none-any.whl Requirement already satisfied (use --upgrade to upgrade): setuptools in /usr/lib/python2.7/site-packages (from zope.interface>=3.6.1->txtorcon>=0.7->ooniprobe) Installing collected packages: ooniprobe, ipaddr, txtorcon, txsocksx, parsley, scapy-real, pypcap, service-identity, pyasn1-modules, characteristic Running setup.py install for ooniprobe /usr/share/GeoIP/GeoIPASNum.dat already exists. Skipping. /usr/share/GeoIP/GeoIP.dat already exists. Skipping. /usr/share/GeoIP/GeoLiteCity.dat already exists. Skipping. changing mode of build/scripts-2.7/oonideckgen from 644 to 755 changing mode of build/scripts-2.7/ooniprobe from 644 to 755 changing mode of build/scripts-2.7/oonireport from 644 to 755 changing mode of build/scripts-2.7/ooniresources from 644 to 755 warning: no files found matching 'data/inputs/' changing mode of /usr/bin/ooniresources to 755 changing mode of /usr/bin/oonireport to 755 changing mode of /usr/bin/ooniprobe to 755 changing mode of /usr/bin/oonideckgen to 755 Running setup.py install for ipaddr Running setup.py install for txsocksx Running setup.py install for parsley Running setup.py install for scapy-real changing mode of build/scripts-2.7/scapy from 644 to 755 changing mode of build/scripts-2.7/UTscapy from 644 to 755 changing mode of /usr/bin/UTscapy to 755 changing mode of /usr/bin/scapy to 755 Running setup.py install for pypcap Found pcap headers in /usr/include/pcap/pcap.h Found libraries in /usr/lib64/libpcap.so found pcap_setnonblock found pcap_compile_nopcap function found pcap_file function building 'pcap' extension gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap.c -o build/temp.linux-x86_64-2.7/pcap.o pcap.c: In function ‘__pyx_pf_4pcap_3bpf_2filter’: pcap.c:1395:52: warning: passing argument 2 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘const char **’ but argument is of type ‘char **’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1395:66: warning: passing argument 3 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘Py_ssize_t *’ but argument is of type ‘int *’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1416:58: warning: pointer targets in passing argument 2 of ‘bpf_filter’ differ in signedness [-Wpointer-sign] __pyx_t_1 = ((bpf_filter(__pyx_v_self->fcode.bf_insns, __pyx_v_p, __pyx_v_n, __pyx_v_n) == 0) != 0); ^ In file included from /usr/include/pcap/pcap.h:49:0, from pcap.c:343: /usr/include/pcap/bpf.h:1474:14: note: expected ‘const u_char *’ but argument is of type ‘char *’ extern u_int bpf_filter(const struct bpf_insn *, const u_char *, u_int, u_int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_16dispatch’: pcap.c:3135:68: warning: passing argument 3 of ‘pcap_dispatch’ from incompatible pointer type __pyx_v_n = pcap_dispatch(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_f_4pcap___pcap_handler, ((unsigned char *)(&__pyx_v_ctx))); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:373:5: note: expected ‘pcap_handler’ but argument is of type ‘void (*)(void *, struct pcap_pkthdr *, char *)’ int pcap_dispatch(pcap_t *, int, pcap_handler, u_char *); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_18loop’: pcap.c:3364:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_20sendpacket’: pcap.c:3619:61: warning: pointer targets in passing argument 2 of ‘pcap_sendpacket’ differ in signedness [-Wpointer-sign] __pyx_v_ret = pcap_sendpacket(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_t_2); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:384:5: note: expected ‘const u_char *’ but argument is of type ‘char *’ int pcap_sendpacket(pcap_t *, const u_char *, int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_28__next__’: pcap.c:3976:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap_ex.c -o build/temp.linux-x86_64-2.7/pcap_ex.o pcap_ex.c:18:23: fatal error: pcap-int.h: No such file or directory # include <pcap-int.h> ^ compilation terminated. error: command 'gcc' failed with exit status 1 Complete output from command /usr/bin/python -c "import setuptools, tokenize;__file__='/tmp/pip-build-YH9MXT/pypcap/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-X1iDfG-record/install-record.txt --single-version-externally-managed --compile: Found pcap headers in /usr/include/pcap/pcap.h Found libraries in /usr/lib64/libpcap.so found pcap_setnonblock found pcap_compile_nopcap function found pcap_file function running install running build running build_ext building 'pcap' extension creating build creating build/temp.linux-x86_64-2.7 gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap.c -o build/temp.linux-x86_64-2.7/pcap.o pcap.c: In function ‘__pyx_pf_4pcap_3bpf_2filter’: pcap.c:1395:52: warning: passing argument 2 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘const char **’ but argument is of type ‘char **’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1395:66: warning: passing argument 3 of ‘PyObject_AsCharBuffer’ from incompatible pointer type __pyx_t_1 = ((PyObject_AsCharBuffer(__pyx_v_buf, (&__pyx_v_p), (&__pyx_v_n)) < 0) != 0); ^ In file included from /usr/include/python2.7/Python.h:133:0, from pcap.c:16: /usr/include/python2.7/abstract.h:476:22: note: expected ‘Py_ssize_t *’ but argument is of type ‘int *’ PyAPI_FUNC(int) PyObject_AsCharBuffer(PyObject *obj, ^ pcap.c:1416:58: warning: pointer targets in passing argument 2 of ‘bpf_filter’ differ in signedness [-Wpointer-sign] __pyx_t_1 = ((bpf_filter(__pyx_v_self->fcode.bf_insns, __pyx_v_p, __pyx_v_n, __pyx_v_n) == 0) != 0); ^ In file included from /usr/include/pcap/pcap.h:49:0, from pcap.c:343: /usr/include/pcap/bpf.h:1474:14: note: expected ‘const u_char *’ but argument is of type ‘char *’ extern u_int bpf_filter(const struct bpf_insn *, const u_char *, u_int, u_int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_16dispatch’: pcap.c:3135:68: warning: passing argument 3 of ‘pcap_dispatch’ from incompatible pointer type __pyx_v_n = pcap_dispatch(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_f_4pcap___pcap_handler, ((unsigned char *)(&__pyx_v_ctx))); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:373:5: note: expected ‘pcap_handler’ but argument is of type ‘void (*)(void *, struct pcap_pkthdr *, char *)’ int pcap_dispatch(pcap_t *, int, pcap_handler, u_char *); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_18loop’: pcap.c:3364:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_20sendpacket’: pcap.c:3619:61: warning: pointer targets in passing argument 2 of ‘pcap_sendpacket’ differ in signedness [-Wpointer-sign] __pyx_v_ret = pcap_sendpacket(__pyx_v_self->__pyx___pcap, __pyx_t_1, __pyx_t_2); ^ In file included from pcap.c:343:0: /usr/include/pcap/pcap.h:384:5: note: expected ‘const u_char *’ but argument is of type ‘char *’ int pcap_sendpacket(pcap_t *, const u_char *, int); ^ pcap.c: In function ‘__pyx_pf_4pcap_4pcap_28__next__’: pcap.c:3976:74: warning: passing argument 3 of ‘pcap_ex_next’ from incompatible pointer type __pyx_v_n = pcap_ex_next(__pyx_v_self->__pyx___pcap, (&__pyx_v_hdr), (&__pyx_v_pkt)); ^ In file included from pcap.c:344:0: pcap_ex.h:13:7: note: expected ‘u_char **’ but argument is of type ‘char **’ int pcap_ex_next(pcap_t *pcap, struct pcap_pkthdr **hdr, u_char **pkt); ^ gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DHAVE_PCAP_INT_H=1 -DHAVE_PCAP_SETNONBLOCK=1 -DHAVE_PCAP_COMPILE_NOPCAP=1 -DHAVE_PCAP_FILE=1 -I/usr/include/pcap -I/usr/include/python2.7 -c pcap_ex.c -o build/temp.linux-x86_64-2.7/pcap_ex.o pcap_ex.c:18:23: fatal error: pcap-int.h: No such file or directory # include <pcap-int.h> ^ compilation terminated. error: command 'gcc' failed with exit status 1 ---------------------------------------- Cleaning up... Command /usr/bin/python -c "import setuptools, tokenize;__file__='/tmp/pip-build-YH9MXT/pypcap/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-X1iDfG-record/install-record.txt --single-version-externally-managed --compile failed with error code 1 in /tmp/pip-build-YH9MXT/pypcap Traceback (most recent call last): File "/bin/pip", line 11, in <module> sys.exit(main()) File "/usr/lib/python2.7/site-packages/pip/__init__.py", line 184, in main return command.main(cmd_args) File "/usr/lib/python2.7/site-packages/pip/basecommand.py", line 161, in main text = '\n'.join(complete_log) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 24: ordinal not in range(128) [1:18:05][~]$ yum provides pcap-int.h Loaded plugins: auto-update-debuginfo, langpacks (cut) No matches found Cheers, d33tah

2 3

Is there a way to get all tor hidden service list???
by Liste 15 May '15

15 May '15

This is my TOR experiments: I was create some hidden services: Don't use standard port for SSH The server's uses a weak password in a virtual machine. Keep secret the hidden service address. Only tor can connect to the net. 2/3 server was scanned via SSL login bruteforce. What is the way to know the non publicated hidden service address? Somebody can download he HS descriptors from tor network?

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev