March 2019 - tor-dev - lists.torproject.org

What happens to my hidden service?
by Liste 29 Dec '25

29 Dec '25

Hidden service is unavailable, but tor is running. Tor's log: Dec 12 18:10:27.000 [notice] Your Guard SECxFreeBSD64 ($D7DB8E82604F806766FC3F80213CF719A0481D0B) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 199/285. Use counts are 101/101. 253 circuits completed, 0 were unusable, 54 collapsed, and 15 timed out. For reference, your timeout cutoff is 60 seconds. is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could also mean an attack against you or potentially the guard itself. Dec 12 18:15:53.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service xxxxxxxxxxxxxxx. Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. [268 similar message(s) suppressed in last 600 seconds] Dec 11 13:43:12.000 [warn] onion_skin_client_handshake failed. Dec 11 13:43:12.000 [warn] circuit_finish_handshake failed. Dec 11 13:43:12.000 [warn] connection_edge_process_relay_cell (at origin) failed. Dec 11 00:34:57.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service .... Dec 10 10:09:01.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:03.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:04.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 12:42:19.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t.

3 2

the consequences of deprecating debian alpha repos with every new major branch
by nusenu 21 Dec '21

21 Dec '21

Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

4 7

tor relay process health data for operators (controlport)
by nusenu 16 Nov '20

16 Nov '20

Hi, every now and then I'm in contact with relay operators about the "health" of their relays. Following these 1:1 discussions and the discussion on tor-relays@ I'd like to rise two issues with you (the developers) with the goal to help improve relay operations and end user experience in the long term: 1) DNS (exits only) 2) tor relay health data 1) DNS ------ Current situation: Arthur Edelstein provides public measurements to tor exit relay operators via his page at: https://arthuredelstein.net/exits/ This page is updated once daily. the process to use that data looks like this: - first they watch Arthur's measurement results - if their failure rate is non-zero they try to tweak/improve/change their setup - wait for another 24 hours (next measurement) This is a somewhat suboptimal and slow feedback loop and is probably also less accurate and less valuable data when compared to the data the tor process can provide. Suggestion for improvement: Exposes the following DNS status information via tor's controlport to help debug and detect DNS issues on exit relays: (total numbers since startup) - amount of DNS queries send to the resolver - amount of DNS queries send to the resolver due to a RESOLVE request - DNS queries send to resolver due to a reverse RESOLVE request - amount of queries that did not result in any answer from the resolver - breakdown of number of responses by response code (RCODE) https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… - max amount of DNS queries send per curcuit If this causes a significant performance impact this feature should be disabled by default. 2) general relay health metrics -------------------------------- Compared to other server daemons (webserver, DNS server, ..) tor provides little data for operators to detect operational issues and anomalies. I'd suggest to provide the following stats via the control port: (most of them are already written to logfiles by default but not accessible via the controlport as far as I've seen) - total amount of memory used by the tor process - amount of currently open circuits - circuit handshake stats (TAP / NTor) DoS mitigation stats - amount of circuits killed with too many cells - amount of circuits rejected - marked addresses - amount of connections closed - amount of single hop clients refused - amount of closed/failed circuits broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1402 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1994 - amount of closed/failed OR connections broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2205 If this causes a significant performance impact this feature should be disabled by default. cell stats - extra info cell stats as defined in: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1072 This data should be useful to answer the following questions: - High level questions: Is the tor relay healthy? - is it hitting any resource limits? - is the tor process under unusual load? - why is tor using more memory? - is it slower than usual at handling circuits? - can the DNS resolver handle the amount of DNS queries tor is sending it? This data could help prevent errors from occurring or provide additional data when trying to narrow down issues. When it comes to the question: **Is it "safe" to make this data accessible via the controlport?** I assume it is safe for all information that current versions of tor writes to logfiles or even publishes as part of its extra info descriptor. Should tor provide this or similar data I'm planing to write scripts for operators to make use of that data (for example a munin plugin that connects to tor's controlport). I'm happy to help write updates for control-spec should these features seem reasonable to you. Looking forward to hearing your feedback. nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

5 7

DNS-over-HTTPS (DOH) in Firefox/Torbrowser
by nusenu 01 Jul '20

01 Jul '20

Hi, since Mozilla did tests [0] on DOH [1] in Firefox I was wondering if Torbrowser developers have put any thought into that as well? Note: I'm _not_ suggesting to use DOH in torbrowser I'm just asking because the answer probably matters for exit documentation in the relay guide if clients do DNS themselves over TCP connections instead of relying on the exit (even if torbrowser is not the only tor client). thanks, nusenu [0] https://www.ghacks.net/2018/03/20/firefox-dns-over-https-and-a-worrying-shi… [1] https://datatracker.ietf.org/doc/draft-hoffman-dns-over-https/ -- https://mastodon.social/@nusenu twitter: @nusenu_

4 4

Lets give every circuit its own exit IP?
by nusenu 18 Mar '20

18 Mar '20

The unbearable situation with Google's reCAPTCHA motivated this email (but it is not limited to this specific case). This idea came up when seeing a similar functionality in unbound (which has it for a different reason). Assumption: There are systems that block some tor exit IP addresses (most likely the bigger once), but they are not blocked due to the fact that they are tor exits. It just occurred that the IP got flagged because of "automated / malicious" requests and IP reputation systems. What if every circuit had its "own" IP address at the exit relay to avoid causing collateral damage to all users of the exit if one was bad? (until the exit runs out of IPs and starts to recycle previously used IPs again) The goal is to avoid accumulating a bad "reputation" for the single used exit IP address that affects all tor users of that exit. Instead of doing it on the circuit level you could do it based on time. Change the exit IP every 5 minutes (but do _not_ change the exit IPs for _existing_ circuits even if they live longer than 5 minutes). Yes, no one has that many IPv4 addresses but with the increasing availability of IPv6 at exits and destinations, this could be feasible to a certain extend, depending on how many IPv6 addresses the exit operator has. There are exit operators that have entire /48 IPv6 blocks. problems: - will not solve anything since reputation will shift to netblocks as well (How big of a netblock are you willing to block?) - you can tell two tor users easily apart from each other even if they use the same exit (or more generally: you can tell circuits apart). There might be all kinds of bad implications that I'm not thinking off right now. - check.tpo would no longer be feasible - how can do we still provide the list of exit IPs for easy blocking? Exits could signal their used netblock via their descriptor. What if they don't? (that in turn opens new kinds of attacks where an exit claims to be /0 and the target effectively blocks everything) - more state to track and store at the exit -... some random thoughts, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

New revision: Proposal 295: Using ADL for relay cryptography (solving the crypto-tagging attack)
by Nick Mathewson 11 Jul '19

11 Jul '19

Hi! I'm sending a new version of proposal 295 from Tomer Ashur, Orr Dunkelman, and Atul Luykx. It's an updated version of their design for an improved relay cell encryption scheme, to prevent tagging attacks. This proposal is checked into the torspec repository. I'm also linking to a diagram for this scheme (and its latex source) from Atul Luykx: https://people.torproject.org/~nickm/prop295/ Finally, I have a draft python reference implementation for an older version of this proposal. I hope to be updating it soon and sending out a link next week. cheers! -- Nick Filename: 295-relay-crypto-with-adl.txt Title: Using ADL for relay cryptography (solving the crypto-tagging attack) Author: Tomer Ashur, Orr Dunkelman, Atul Luykx Created: 22 Feb 2018 Last-Modified: 1 March 2019 Status: Open 0. Context Although Crypto Tagging Attacks were identified already in the original Tor design, it was not before the rise of the Procyonidae in 2012 that their severity was fully realized. In Proposal 202 (Two improved relay encryption protocols for Tor cells) Nick Mathewson discussed two approaches to stymie tagging attacks and generally improve Tor's cryptography. In Proposal 261 (AEZ for relay cryptography) Mathewson puts forward a concrete approach which uses the tweakable wide-block cipher AEZ. This proposal suggests an alternative approach to Proposal 261 using the notion of Release (of) Unverified Plaintext (RUP) security. It describes an improved algorithm for circuit encryption based on CTR-mode which is already used in Tor, and an additional component for hashing. Incidentally, and similar to Proposal 261, this proposal employs the ENCODE-then-ENCIPHER approach thus it improves Tor's E2E integrity by using (sufficient) redundancy. For more information about the scheme and a security proof for its RUP-security see Tomer Ashur, Orr Dunkelman, Atul Luykx: Boosting Authenticated Encryption Robustness with Minimal Modifications. CRYPTO (3) 2017: 3-33 available online at https://eprint.iacr.org/2017/239 . For authentication between the OP and the edge node we use the PIV scheme: https://eprint.iacr.org/2013/835 2. Preliminaries 2.1 Motivation For motivation, see proposal 202. 2.2. Notation Symbol Meaning ------ ------- M Plaintext C_I Ciphertext CTR Counter Mode N_I A de/encryption nonce (to be used in CTR-mode) T_I A tweak (to be used to de/encrypt the nonce) T'_I A running digest ^ XOR || Concatenation (This is more readable than a single | but must be adapted before integrating the proposal into tor-spec.txt) 2.3. Security parameters HASH_LEN -- The length of the hash function's output, in bytes. PAYLOAD_LEN -- The longest allowable cell payload, in bytes. (509) DIG_KEY_LEN -- The key length used to digest messages (e.g., using GHASH). Since GHASH is only defined for 128-bit keys, we recommend DIG_KEY_LEN = 128. ENC_KEY_LEN -- The key length used for encryption (e.g., AES). We recommend ENC_KEY_LEN = 128. 2.4. Key derivation (replaces Section 5.2.2) For newer KDF needs, Tor uses the key derivation function HKDF from RFC5869, instantiated with SHA256. The generated key material is: K = K_1 | K_2 | K_3 | ... where, if H(x,t) denotes HMAC_SHA256 with value x and key t, and m_expand denotes an arbitrarily chosen value, and INT8(i) is an octet with the value "i", then K_1 = H(m_expand | INT8(1) , KEY_SEED ) and K_(i+1) = H(K_i | m_expand | INT8(i+1) , KEY_SEED ), in RFC5869's vocabulary, this is HKDF-SHA256 with info == m_expand, salt == t_key, and IKM == secret_input. When used in the ntor handshake a string of key material is generated and is used in the following way: Length Purpose Notation ------ ------- -------- HASH_LEN forward digest IV DF * HASH_LEN backward digest IV DB * ENC_KEY_LEN encryption key Kf ENC_KEY_LEN decryption key Kb DIG_KEY_LEN forward digest key Khf DIG_KEY_LEN backward digest key Khb ENC_KEY_LEN forward tweak key Ktf ENC_KEY_LEN backward tweak key Ktb DIGEST_LEN nonce to use in the * hidden service protocol * I am not sure that we need these any longer. Excess bytes from K are discarded. 2.6. Ciphers For hashing(*) we use GHASH with a DIG_KEY_LEN-bit key. We write this as Digest(K,M) where K is the key and M the message to be hashed. We use AES with an ENC_KEY_LEN-bit key. For AES encryption (resp., decryption) we write E(K,X) (resp., D(K,X)) where K is an ENC_KEY_LEN-bit key and X the block to be encrypted (resp., decrypted). For a stream cipher, unless otherwise specified, we use ENC_KEY_LEN-bit AES in counter mode, with a nonce that is generated as explained below. We write this as Encrypt(K,N,X) (resp., Decrypt(K,N,X)) where K is the key, N the nonce, and X the message to be encrypted (resp., decrypted). (*) The terms hash and digest are used interchangeably. 3. Routing relay cells 3.1. Forward Direction The forward direction is the direction that CREATE/CREATE2 cells are sent. 3.1.1. Routing from the Origin Let n denote the integer representing the destination node. For I = 1...n+1, T'_{I} is initialized to the 128-bit string consisting entirely of '0's. When an OP sends a relay cell, they prepare the cell as follows: The OP prepares the authentication part of the message: C_{n+1} = M T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0) T'_{n+1} = T_{n+1} Then, the OP prepares the multi-layered encryption: For I=n...1: C_I = Encrypt(Kf_I,N_{I+1},C_{I+1}) T_I = Digest(Khf_I,T'_I||C_I) N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1}) T'_I = T_I The OP sends C_1 and N_1 to node 1. 3.1.2. Relaying Forward at Onion Routers When a forward relay cell is received by OR I, it decrypts the payload with the stream cipher, as follows: 'Forward' relay cell: T_I = Digest(Khf_I,T'_I||C_I) N_{I+1} = T_I ^ D(Ktf_I,T_I ^ N_I) C_{I+1} = Decrypt(Kf_I,N_{I+1},C_I) T'_I = T_I The OR then decides whether it recognizes the relay cell as described below. If the OR recognizes the cell, it processes the contents of the relay cell. Otherwise, it passes C_{I+1}||N_{I+1} along the circuit if the circuit continues. For more information, see section 4 below. 3.2. Backward Direction The backward direction is the opposite direction from CREATE/CREATE2 cells. 3.2.1. Relaying Backward at Onion Routers When a backward relay cell is received by OR I, it encrypts the payload with the stream cipher, as follows: 'Backward' relay cell: T_I = Digest(Khb_I,T'_I||C_{I+1}) N_I = T_I ^ E(Ktb_I,T_I ^ N_{I+1}) C_I = Encrypt(Kb_I,N_I,C_{I+1}) T'_I = T_I with C_{n+1} = M and N_{n+1}=0. Once encrypted, the node passes C_I and N_I along the circuit towards the OP. 3.2.2. Routing to the Origin When a relay cell arrives at an OP, the OP decrypts the payload with the stream cipher as follows: OP receives relay cell from node 1: For I=1...n, where n is the end node on the circuit: C_{I+1} = Decrypt(Kb_I,N_I,C_I) T_I = Digest(Khb_I,T'_I||C_{I+1}) N_{I+1} = T_I ^ D(Ktb_I,T_I ^ N_I) T'_I = T_I If the payload is recognized (see Section 4.1), then: The sending node is I. Stop, process the payload and authenticate. 4. Application connections and stream management 4.1. Relay cells Within a circuit, the OP and the end node use the contents of RELAY packets to tunnel end-to-end commands and TCP connections ("Streams") across circuits. End-to-end commands can be initiated by either edge; streams are initiated by the OP. The payload of each unencrypted RELAY cell consists of: Relay command [1 byte] 'Recognized' [2 bytes] StreamID [2 bytes] Length [2 bytes] Data [PAYLOAD_LEN-23 bytes] The 'recognized' field is used as a simple indication that the cell is still encrypted. It is an optimization to avoid calculating expensive digests for every cell. When sending cells, the unencrypted 'recognized' MUST be set to zero. When receiving and decrypting cells the 'recognized' will always be zero if we're the endpoint that the cell is destined for. For cells that we should relay, the 'recognized' field will usually be nonzero, but will accidentally be zero with P=2^-16. If the cell is recognized, the node moves to verifying the authenticity of the message as follows(*): forward direction (executed by the end node): T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1}) T'_{n+1} = T_{n+1} The message is authenticated (i.e., M = C_{n+1}) if and only if Tag = 0 backward direction (executed by the OP): The message is authenticated (i.e., C_{n+1} = M) if and only if N_{n+1} = 0 The old Digest field is removed since sufficient information for authentication is now included in the nonce part of the payload. (*) we should consider dropping the 'recognized' field altogether and always try to authenticate. Note that this is an optimization question and the crypto works just as well either way. The 'Length' field of a relay cell contains the number of bytes in the relay payload which contain real payload data. The remainder of the payload is padding bytes. 4.2. Appending the encrypted nonce and dealing with version-homogenic and version-heterogenic circuits When a cell is prepared to be routed from the origin (see Section 3.1.1) the encrypted nonce N is appended to the encrypted cell (occupying the last 16 bytes of the cell). If the cell is prepared to be sent to a node supporting the new protocol, S is combined with other sources to generate the layer's nonce. Otherwise, if the node only supports the old protocol, n is still appended to the encrypted cell (so that following nodes can still recover their nonce), but a synchronized nonce (as per the old protocol) is used in CTR-mode. When a cell is sent along the circuit in the 'backward' direction, nodes supporting the new protocol always assume that the last 16 bytes of the input are the nonce used by the previous node, which they process as per Section 3.2.1. If the previous node also supports the new protocol, these cells are indeed the nonce. If the previous node only supports the old protocol, these bytes are either encrypted padding bytes or encrypted data. 5. Security 5.1. Resistance to crypto-tagging attacks A crypto-tagging attack involves a circuit with two colluding nodes and at least one honest node between them. The attack works when one node makes a change to the cell (tagging) in a way that can be undone by the other colluding party. In between, the tagged cell is processed by honest nodes which do not detect the change. The attack is possible due to the malleability property of CTR-mode: a change to a ciphertext bit effects only the respective plaintext bit in a predicatble way. This proposal frustrates the crypto-tagging attack by linking the nonce to the encrypted message such that any change to the ciphertext results in a random nonce and hence, random plaintext. Let us consider the following 3-hop scenario: the entry and end nodes are malicious and colluding and the middle node is honest. 5.1.1. forward direction Suppose that node I tags the ciphertext part of the message (C'_{I+1} != C_{I+1}) then forwards it to the next node (I+1). As per Section 3.1.2. Node I+1 digests C'_{I+1} to generate T_{I+1} and N_{I+2}. Since C'_{I+2} is different than it should be, so are the resulting T_{I+1} and N_{I+2}. Hence, decrypting C'_{I+2} using these values results in a random string for C_{I+2}. Since C_{I+2} is now just a random string, it is decrypted into a random string and cannot be 'recognized' nor authenticated. Furthermore, since C'_{I+1} is different than what it should be, T'_{I+1} (i.e., the running digest of the middle node) is now out of sync with that of the OP, which means that all future cells sent through this node will decrypt into garbage (random strings). Likewise, suppose that instead of tagging the ciphertext, Node I node tags the encrypted nonce N'_{I+1} != N_{I+1}. Now, when Node I+1 digests the payload the tweak T_{I+1} is find, but using it to decrypt N'_{I+1} again results in a random nonce for N_{I+2}. This random nonce is used to decrypt C_{I+1} into a random C'_{I+2} which is not recognized by the end node. Since C_{I+2} is now a random string, the running digest of the end node is now out of sync, which prevents the end node from decrypting further cells. 5.1.2. Backward direction In the backward direction the tagging is done by Node I+2 untagging by the Node I. Suppose first that Node I+2 tags the ciphertext C_{I+2} and sends it to Node I+1. As per Section 3.2.1, Node I+1 first digests C_{I+2} and uses the resulting T_{I+1} to generate a nonce N_{I+1}. From this it is clear that any change introduced by Node I+2 influences the entire payload and cannot be removed by Node I. Unlike in Section 5.1.1., the cell is blindly delivered by Node I to the OP which decrypts it. However, since the payload leaving the end node was modified, the message cannot be authenticated by the OP which can be trusted to tear down the circuit. Suppose now that tagging is done by Node I+2 to the nonce part of the payload, i.e., N_{I+2}. Since this value is encrypted by Node I+1 to generate its own nonce N_{I+1}, again, a random nonce is used which affects the entire keystream of CTR-mode. The cell again cannot be authenticated by the OP and the circuit is torn down. We note that the end node can modify the plain message before ever encrypting it and this cannot be discovered by the Tor protocol. This vulnerability is outside the scope of this proposal and users should always use TLS to make sure that their application data is encrypted before it enters the Tor network. 5.2. End-to-end authentication Similar to the old protocol, this proposal only offers end-to-end authentication rather than per-hop authentication. However, unlike the old protocol, the ADL-construction is non-malleable and hence, once a non-authentic message was processed by an honest node supporting the new protocol, it is effectively destroyed for all nodes further down the circuit. This is because the nonce used to de/encrypt all messages is linked to (a digest of) the payload data. As a result, while honest nodes cannot detect non-authentic messages, such nodes still destroy the message thus invalidating its authentication tag when it is checked by edge nodes. As a result, security against crypto-tagging attacks is ensured as long as an honest node supporting the new protocol processes the message between two dishonest ones. 5.3 The Running Digest Unlike the old protocol, the running digest is now computed as the output of a GHASH call instead of a hash function call (SHA256). Since GHASH does not provide the same type of security guarantees as SHA256, it is worth discussing why security is not lost from computing the running digest differently. The running digets is used to ensure that if the same payload is encrypted twice, then the resulting ciphertext does not remain the same. Therefore, all that is needed is that the digest should repeat with low probability. GHASH is a universal hash function, hence it gives such a guarantee assuming its key is chosen uniformly at random.

3 4

Re: [tor-dev] Docker images for help people to run Tor (teor)
by Alessandro Fiori 31 Mar '19

31 Mar '19

Hi, I would like to share with the community some tests I've made for setting up a "swarm" of Tor relays. I setted up 3 exit relays and 3 middle relays on the same IPv4 address, to make some testing, and the entire swarm works like a charm. Due to Tor limitation, I have decided to build a template for preparing the cluster, and upload it to GitHub. You can find the example mini-cluster here: https://github.com/randomtable/ChimeraOS/tree/master/TorSwarm I have tested the exit capabilities on another network with different public IP address. All the relays have published their own descriptors, I have prepared the containers as a single, separated machines. The process is different from preparing a single relay, because of Docker build process. I have disabled caching during the cluster process, so i have been able to modify torrc without issues. Because its very interesting, attached to this e-mail there is the console Logs from the 6 relays. All containers are read-only, so the entire relay will destroy at the end of session. I hope this can be useful. Alessandro Fiori Il giorno sab 30 mar 2019 alle ore 13:00 < tor-dev-request(a)lists.torproject.org> ha scritto: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Docker images for help people to run Tor (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 30 Mar 2019 13:08:53 +1000 > From: teor <teor(a)riseup.net> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Docker images for help people to run Tor > Message-ID: <3D4905AF-1C10-47BF-8823-EB3228FF990F(a)riseup.net> > Content-Type: text/plain; charset="utf-8" > > Hi, > > (Please try to reply to the thread, not the digest!) > > > On 30 Mar 2019, at 11:51, Alessandro Fiori <alefiori3(a)gmail.com> wrote: > > > > Because the images are built separately, and Containers doesn't have > persistent data by default, i'm testing the launch of a "relay swarm", > which isn't the "Docker Swarm". > > The concept of a "Relay swarm" is to have multiple running relay > containers on the same user machine, without any conflict. > > > > The idea (i will testing it very soon) is possible, by pulling an image > and running it multiple times, creating intermetiate containers. > > > > A function like the "relay swarm" can be very useful, i don't know if > this approach can be risky, so i'm preparing a script for launching only > one type of relay swarm (middle or exit relays). > > > > If there is no security concerns, this function will be a very key > function for grow up the Network, because a user can run multiple relays at > a time. > > Tor only allows 2 relays per IPv4 address. > > T >

2 1

Re: [tor-dev] tor-dev Digest, Vol 98, Issue 18
by Alessandro Fiori 29 Mar '19

29 Mar '19

Hi, and thanks for replying! I have built another image, for Non-Exit relays. Essentially, the Dockerfile is the same to the Dockerfile for build an Exit Relay, i have added the command for uncomment "ExitRelay 0" line in the torrc file. I have modified the Hidden Service image too, providing only the Hidden Service without opening ports, reducing the attack surface. Because the images are built separately, and Containers doesn't have persistent data by default, i'm testing the launch of a "relay swarm", which isn't the "Docker Swarm". The concept of a "Relay swarm" is to have multiple running relay containers on the same user machine, without any conflict. The idea (i will testing it very soon) is possible, by pulling an image and running it multiple times, creating intermetiate containers. A function like the "relay swarm" can be very useful, i don't know if this approach can be risky, so i'm preparing a script for launching only one type of relay swarm (middle or exit relays). If there is no security concerns, this function will be a very key function for grow up the Network, because a user can run multiple relays at a time. I'm presenting this project to the large community, so i can receive feedback and take actions in case of issues. Kind regards, Alessandro Fiori Il giorno ven 29 mar 2019 alle ore 13:00 < tor-dev-request(a)lists.torproject.org> ha scritto: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Docker images for help people to run Tor > (Chelsea Holland Komlo) > 2. Re: Docker images for help people to run Tor (Alessandro Fiori) > 3. Re: Docker images for help people to run Tor (teor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Mar 2019 05:46:57 -0700 > From: Chelsea Holland Komlo <me(a)chelseakomlo.com> > To: tor-dev(a)lists.torproject.org > Cc: Alessandro Fiori <alefiori3(a)gmail.com> > Subject: Re: [tor-dev] Docker images for help people to run Tor > Message-ID: <554cdbb2a021c08e08faef91d3bcb9a2(a)chelseakomlo.com> > Content-Type: text/plain; charset=US-ASCII > > Hi, > > Thanks for this information and putting this together! Making relays > easier to run is always a helpful thing to us. > > We have a wiki page to aggregate relay infrastructure projects such as > this. If you can add your projects to this page (and any required > instructions), that would be great. > > > https://trac.torproject.org/projects/tor/wiki/community/relay_infrastructure > > Thanks for the contribution! > Chelsea > > On 2019-03-27 21:18, Alessandro Fiori wrote: > > Hi, I'm an Italian developer who want to help development and grow up > > the Tor network. > > I would like to share with you an idea to grow up the Tor Network. > > Working with Docker, i have released two images, a Tor Exit Relay > > image (named "tor-relay") and an image (named "torworld-template"). > > The idea is to use Docker and build images for facilitate users to run > > a Tor Relay or an Hidden Service. > > The two images are located on Docker Hub in this locations: > > > > Tor Exit Relay: https://hub.docker.com/r/alessandrofiori/tor-relay > > Tor Machine Template: > > https://hub.docker.com/r/alessandrofiori/torworld-template > > > > If you want to see how the images are built, please check the > > following Dockerfile > > > > Tor Exit Relay: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > Tor Machine Template: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > > > If you want to see how i automate the build and push process, please > > check the following script: > > > > Process with system cleanup: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-script… > > Process for rolling release: > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-rollin… > > > > Actually i'm working in a Windows environment, i will release ubuntu > > scripts soon. > > > > I would like to share with everyone, so if this can be helpful, this > > can be a starting point for build up images for help people to run > > relays or hidden services. > > > > This kind of approach can be reduce costs for people who want to run a > > relay or an hidden service, and can be an help for building a more > > censorship-resistant platform, by using a Docker Swarm, and > > replicating instances. > > > > Waiting for your reply as soon as possible, i'm very curious if this > > project can be helpful for Tor Project! > > > > Kind regards (and thanks for your hard work) > > Alessandro Fiori > > _______________________________________________ > > tor-dev mailing list > > tor-dev(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Mar 2019 23:57:46 +0100 > From: Alessandro Fiori <alefiori3(a)gmail.com> > To: Chelsea Holland Komlo <me(a)chelseakomlo.com> > Cc: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Docker images for help people to run Tor > Message-ID: > <CAP6e1PnzqMRXdGmnF1U=oZqA2s69gdY= > Wc+D4LSzPsygbYckNw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, and thanks for reply! > I added a line in the dedicated page, and modified the README.md on GitHub > for more specific informations to the users. > > I've decided to release two scripts (I'm releasing for Ubuntu too), for run > an Exit Relay or Hidden Service then, with Docker image. > > If needed, let me know if there would be useful releasing an image of a > Non-Exit-Relay. > > I will add more informations in the following days, for more explanations > and specific infos about building process. > I have decided to release only scripts or text file (for build process and > pull process), and no binaries, to keep processes transparent and > controllable. > > The next step for me is writing to forums and IRC, so people can review the > configurations. > I would like to meet the best practices to provide a robust and secure > service under all aspects. > > Another further step will be to contact Docker and try to achieve the > "Verified Publisher" or "Official Image" status, to keep the User Trust up. > > Official Images have automated security scans, so it can be a benefit to > community. > > I hope this can be useful, let me know! > > Kind regards (and thanks for your hard work... really!) > > Il giorno gio 28 mar 2019 alle ore 13:46 Chelsea Holland Komlo < > me(a)chelseakomlo.com> ha scritto: > > > Hi, > > > > Thanks for this information and putting this together! Making relays > > easier to run is always a helpful thing to us. > > > > We have a wiki page to aggregate relay infrastructure projects such as > > this. If you can add your projects to this page (and any required > > instructions), that would be great. > > > > > > > https://trac.torproject.org/projects/tor/wiki/community/relay_infrastructure > > > > Thanks for the contribution! > > Chelsea > > > > On 2019-03-27 21:18, Alessandro Fiori wrote: > > > Hi, I'm an Italian developer who want to help development and grow up > > > the Tor network. > > > I would like to share with you an idea to grow up the Tor Network. > > > Working with Docker, i have released two images, a Tor Exit Relay > > > image (named "tor-relay") and an image (named "torworld-template"). > > > The idea is to use Docker and build images for facilitate users to run > > > a Tor Relay or an Hidden Service. > > > The two images are located on Docker Hub in this locations: > > > > > > Tor Exit Relay: https://hub.docker.com/r/alessandrofiori/tor-relay > > > Tor Machine Template: > > > https://hub.docker.com/r/alessandrofiori/torworld-template > > > > > > If you want to see how the images are built, please check the > > > following Dockerfile > > > > > > Tor Exit Relay: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > > Tor Machine Template: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… > > > > > > If you want to see how i automate the build and push process, please > > > check the following script: > > > > > > Process with system cleanup: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-script… > > > Process for rolling release: > > > > > > https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-rollin… > > > > > > Actually i'm working in a Windows environment, i will release ubuntu > > > scripts soon. > > > > > > I would like to share with everyone, so if this can be helpful, this > > > can be a starting point for build up images for help people to run > > > relays or hidden services. > > > > > > This kind of approach can be reduce costs for people who want to run a > > > relay or an hidden service, and can be an help for building a more > > > censorship-resistant platform, by using a Docker Swarm, and > > > replicating instances. > > > > > > Waiting for your reply as soon as possible, i'm very curious if this > > > project can be helpful for Tor Project! > > > > > > Kind regards (and thanks for your hard work) > > > Alessandro Fiori > > > _______________________________________________ > > > tor-dev mailing list > > > tor-dev(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > >

2 1

Docker images for help people to run Tor
by Alessandro Fiori 28 Mar '19

28 Mar '19

Hi, I'm an Italian developer who want to help development and grow up the Tor network. I would like to share with you an idea to grow up the Tor Network. Working with Docker, i have released two images, a Tor Exit Relay image (named "tor-relay") and an image (named "torworld-template"). The idea is to use Docker and build images for facilitate users to run a Tor Relay or an Hidden Service. The two images are located on Docker Hub in this locations: Tor Exit Relay: https://hub.docker.com/r/alessandrofiori/tor-relay Tor Machine Template: https://hub.docker.com/r/alessandrofiori/torworld-template If you want to see how the images are built, please check the following Dockerfile Tor Exit Relay: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… Tor Machine Template: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/DockerFile-T… If you want to see how i automate the build and push process, please check the following script: Process with system cleanup: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-script… Process for rolling release: https://raw.githubusercontent.com/randomtable/ChimeraOS/master/build-rollin… Actually i'm working in a Windows environment, i will release ubuntu scripts soon. I would like to share with everyone, so if this can be helpful, this can be a starting point for build up images for help people to run relays or hidden services. This kind of approach can be reduce costs for people who want to run a relay or an hidden service, and can be an help for building a more censorship-resistant platform, by using a Docker Swarm, and replicating instances. Waiting for your reply as soon as possible, i'm very curious if this project can be helpful for Tor Project! Kind regards (and thanks for your hard work) Alessandro Fiori

3 3

How to see the translated strings from Release_tweets.md in use
by scootergrisen 23 Mar '19

23 Mar '19

How/Where do i se the translated strings from Transifex Release_tweets.md in use?

1 0