[tor-dev] CVE-2020-8516 Hidden Service deanonymization
Since no one is posting it here and talking about it, I will post it. https://nvd.nist.gov/vuln/detail/CVE-2020-8516 The guy: http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html Is this real? Are we actually not verifying if the IP of the Rend is a node in the Tor network? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Evaluating rendezvous circuit build up CPU usage
Hi, thanks for working on it. At first I thought about using a PoW on the Introduction Point (I.P.) side. Maybe a dynamic PoW? I mean only ask for PoW under load (Hidden services sets the INTRO1s/second on the I.P.) or ask for every new circuit. Then I thought that we need to fix the Rendezvous verification issue too. We do not verify if the client/user/attacker actually opened a circuit to the Rend point. And I thought we could make the Rend sing a message and the I.P verify the signature before sending the INTRO2 to the HS. But now I think we need to merge designs and make just one proposal fixing both problems at the same time. If we don't want to make a PoW for every new circuit, we could make the client generate a private Identity (KeyPair) mixed with some sort of PoW, generating it for every HS a client want to connect. This way we only make PoW for each onion and the IP can have a replay cache (or something like that) with each identity and the last time it requested a new circuit. We can better control with this way the number of individual clients and we "save the planet" by not making a PoW for each new circuit. (Maybe this approach is what your are working at with the "token based approach"). Sorry for my english... El 13/1/20 a las 13:39, Valentin Franck escribió: Hello tor-devs, I am currently working on a DoS mitigation system aiming to protect the availability of onion services flooded with INTRO2 cells. My idea is using a (Privacy Pass like) token based approach as suggested in https://trac.torproject.org/projects/tor/ticket/31223#comment:6 For the evaluation of a first prototype I would like to compare CPU usage times at the onion service when a) launching a rendezvous circuit and b) validating a (potentially invalid) token. Is there an easy way, to measure the CPU time a service spends for all operations triggered when launching a new rendezvous circuit? Has somebody done that before? Basically, I want to measure how much CPU time we save, if we do not launch the rendezvous circuit. So far I have identified the following functions: launch_rendezvous_point_circuit() and service_rendezvous_circ_has_opened(). I understand that there is more operations involved for building new circuits, since circuits are built hop by hop. How can I identify all relevant functions triggered after launching the rendezvous circuit and include them in my measurements? Once I have some reliable results I will provide you with more information on what I am doing and how it is working so far. Cheers Valentin This is my first post on this list :-). So have mercy, if I overlooked resources to answer my question. Also, I am only beginning to familiarize myself with the existing code base. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Request info about how the Tor HS DoS works
Hello, since months ago we are debating proposals about how to stop HS being DDoSed. We have many open issues and even developed in a rush a fix "just for the network" (not HS availability). But, I have not seen yet a good explanation about what is really happening when HS is being DDoSed by this famous and effective attack. I mean, the only thing I know about it is that its goal is to send a ton of INTRODUCE2 cells to the HS, but, what is the cost for the attacker? Some questions need to be answered, at least If I want to understand it and make a proposal for fixing this issues. *Questions:* Is the attacker building a circuit to the Rendz point as expected by the protocol? How can we be sure of that? -Attacker (client) to Rendezvous point circuit: What is exactly happening on this circuit and how can the attacker improve the attack? Is the attacker using the same Rendz over and over for its INTRODUCE1? A new circuit to the Rendz? Can the first two hops of a circuit be reused (only changing the exit node) so it can build a new circuit to a new Rendz faster and make the attack better? -Attacker (client) to Intro point: what is exactly happening on this side of the equation? Sorry, but I could not find the answer to these questions and what is going on on any ticket or this mail lists. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Fwd: Re: Onion Service - Intropoint DoS Defenses
Forwarded Message Subject:Re: [tor-dev] Onion Service - Intropoint DoS Defenses Date: Thu, 4 Jul 2019 20:38:48 +0200 From: juanjo To: David Goulet These experiments and final note confirm what I thought about this rate limiting feature from the start: it is missing important parts. Ok, you can protect the network a little and the HS, but the general availability is not affected so it actually does not help for that. I wanna make a proposal including many things at the same time, but I don't have much time to follow the guidelines to make a official proposal. Maybe in some weeks? Again, I repeat: things that should be done now: -Authenticated rend signature. This would help a lot I think. -Mid-term: PoW for the client when reaching the 305prop limit instead of denying access? IDK, all always configurable. -Deprecate clients or allow the Hidden Service to configure the IP to allow access for old version clients (not supporting new antiDoS features) or not. If we allow old version without protections, all security measures are useless. And just a new idea: what about make the rotation of IP dynamic based on this prop305 values? + time based rotation: One of the goal for rotation was defending against correlation attacks: if we set a lower limit we have a potential DoS (right now), if we set it high we have a potential correlation attack, bigger surface. What about we join time based rotation (ex. 24 hours) + or limit reached based on the prop305 values. On 3/7/19 20:37, David Goulet wrote: On 30 May (09:49:26), David Goulet wrote: Greetings! [snip] Hi everyone, I'm writing here to update on where we are about the introduction rate limiting at the intro point feature. The branch of #15516 (https://trac.torproject.org/15516) is ready to be merged upstream which implements a simple rate/burst combo for controlling the amount of INTRODUCE2 cells that are relayed to the service. As previously detailed in this thread, the default values are a rate of 25 introduction per second and a burst of 200 per second. These values can be controlled by consensus parameters meaning they can be changed network wide. We've first asked big service operators, I'm not going to detail the values they provided us in private, but those defaults are quite large enough to sustain heavy traffic from what we can tell from what they gave us. The second thing we did is do experimental testing to see how CPU usage and availability is affected. We've tested this with 3 _fast_ introduction points and then 3 rate limited introduction points. The good news is that once the attack stops, the rain of introduction requests to the service stops very quickly. With the default rate/burst values, on a Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz (8 cores), the tor service CPU doesn't go above ~60% (on one single core). And almost drops to 0 as soon as the attack ends. The bad news is that availability is _not_ improved. One of the big reasons for that is because the rate limit defenses, once engaged at the intro point, will send back a NACK to the client. A vanilla tor client will stop using that introduction point away for 120 seconds if it gets 3 NACKs from it. This leads to tor quickly giving up on trying to connect and thus telling the client that connection is impossible to the .onion. We've hacked a tor client to play along and stop ignoring the NACKs to see how much time it would take to reach it. On average, a client would roughly need around 70 seconds with more than 40 NACKs on average. However, it varied a _lot_ during our experiments with many outliers from 8 seconds with 1 NACK up to 160 seconds with 88 NACKs. (For this, the SocksTimeout had to be bumped quite a bit). There is an avenue of improvement here to make the intro point sends a specific NACK reason (like "Under heavy load" or ...) which would make the client consider it like "I should retry soon-ish" and thus making the client possibly able to connect after many seconds (or until the SocksTimeout). Another bad news there! We can't do that anytime soon because of this bug that basically crash clients if an unknown status code is sent back (that is a new NACK value):https://trac.torproject.org/30454. So yeah... quite unfortunate there but also a superb reason for everyone out there to upgrade :). One good news is that it seems that having fast intro points instead of slow IPs doesn't change much on the overall load on the service so this for now, our experiment, shows it doesn't matter. Overall, this rate limit feature does two things: 1. Reduce the overall network load. Soaking the introduction requests at the intro point helps avoid the service creating pointless rendezvous circuits which makes it "less" of an amplification attack. 2. Keep the service usable. The tor daemon doesn't go in massive CPU load and thus can be actually used
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
Why do we need to send a challenge to a client on every request? No, it is only the first time when connecting an onion and moreover this should be enabled only when the configured rate limit / antiDoS is reached. SO actually a client will be connecting to the onion like always: with no PoW. If the Intro Point reaches a configured limit, then, it starts challenging the client, only the first time, the first request to that onion. Someone said that my design of adding an extra round to make the PoW step was bad, yes, we could use something unique to that circuit based on ntor. BUT, what is better for performance? Is sending an extra cell better than computing PoW always? etc. -If you add an extra step for PoW: you can enable it only when needed: 1) no DoS? client connects like always and do not make a PoW. 2) DoS? client receives a challenge and computes a PoW. -If you do not add an extra step there is no dynamic way to enable or disable PoW. You bypass the extra step but the client needs to compute PoW every time. The only config aviable is service descriptor where onion can put the "enable pow" and client reads it and sends the PoW to I.P. unless you wanna build something more complex... On 20/6/19 15:41, Chelsea Holland Komlo wrote: On 2019-06-20 00:19, Watson Ladd wrote: On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo wrote: There are a couple approaches to consider. POW via hashing goes for a relatively simple to implement approach. However, this incurs a high cost for all clients, and also environmental damage, per previous email. Another approach similar to the above (but more environmentally friendly) can be Proof of Storage (or proof of space), as in https://eprint.iacr.org/2013/796.pdf With both of the above approaches, there will be a tradeoff to what the cost is to deter a would-be attacker, versus the cost to real but bandwidth/cpu limited clients, such as on mobile platforms. More involved approaches include anonymous blacklists/whitelists, blinded tokens, etc. Previous work has been done in this space, here is one example: https://crysp.uwaterloo.ca/courses/pet/F11/cache/www-users.cs.umn.edu/~hopper/faust-wpes.pdf Privacy Pass has already been integrated into Tor Browser. Perhaps work could be done to use it here? An approach akin to Privacy Pass could be an option to avoid serving challenges to clients with each request (see reference to anonymous tokens above), but it cannot be a drop in fix, of course. Furthermore, an acceptable POW or POS scheme still needs to be selected, the tradeoffs of which we are currently discussing. Better understanding the requirements of the system from George and David will help define which approach is acceptable given the tradeoffs. For example, I imagine accessing onion services should not be restricted to clients from a web browser. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
On 13/6/19 12:21, George Kadianakis wrote: Is this a new cell? What's the format? Are these really keys or are they just nonces? Yes sorry, they are nonces. This was only a proposal for a proposal. Is this a new cell? What's the format? Are these really keys or are they just nonces? IMO we should not do this through a new cell because that increases the round-trip by one. Instead we should just embed the PoW parameters in the onion service descriptor and clients find them there. Yes, this is a new cell triggered only when DoS limit is reached. We can't embed it on the onion service descriptor because the attacker could precompute the PoW and make a dictionary attack. The IPKey (will be a nonce) should unique for each new connecting client that wants to send the INTRODUCE2. What we want this way is increasing the cost of an attacker by many times vs only a little overhead to the I.P. That looks like a naive PoW scheme. It would perhaps be preferable to try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to minimize the advantage of adversaries with GPUs etc.? Are there any good such schemes? Also services should definitely be able to configure the difficulty of the PoW, and IMO this should again happen through the descriptor. That PoW scheme was just a simple example. We should find the right choice. Something hard to find but easy to check. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension
Hello, this is my view of things, please be gentle as this is my first
proposal draft :)
_ADAPTIVE POW PROPOSAL:_
Client sends the INTRODUCE1 as normal.
Introduction Point checks the Current Requests Rate and checks the DoS
settings.
-DoS check is OK: send INTRODUCE2 to Hidden Service etc...
-DoS settings/rate limit reached: then
1.Introduction Point generates a random 8 bytes key (IPKey) and
associates it with the client circuit. Then send INTRODUCE_POW to the
Client with the IPKey.
2.Client computes POW.
Do{
Generates random 8 bytes key (ClientKey).
Generates hash(sha512/256 or sha3??) of
hash(IPKey + ClientKey)
} while (hash does not start with "abcde")
3. Client sends INTRODUCE_POWR to the I.P. with the generated POW
and the ClientKey.
4. I.P. checks the POW:
-POW is correct: send INTRODUCE2 to HS.
-POW is not correct: send INTRODUCE_POW_ERROR to client with
new IPKey.
*I say 8 bytes for the Keys just for example.
PROS AND CONS, who needs to update Tor version?:
--
Only rate limit: Introduction Point and Hidden Service. No breakage.
POW: Client, Introduction Point and Hidden Service. POW will break
compatibility with other v3 Hidden Services clients, if we implement a
way to bypass POW for old clients then this feature won't work as intended.
A forgotten guy here: Authenticated Rends cell: where we make sure the
Client established a connection to the Rend Point before requesting the
INTRODUCE1.
On 12/6/19 14:39, George Kadianakis wrote:
David Goulet writes:
Filename: 305-establish-intro-dos-defense-extention.txt
Title: ESTABLISH_INTRO Cell DoS Defense Extension
Author: David Goulet, George Kadianakis
Created: 06-June-2019
Status: Draft
Thanks for this proposal, it's most excellent and an essential building
block for future work on intro point related defences.
We propose a new EXT_FIELD_TYPE value:
[01] -- DOS_PARAMETERS.
If this flag is set, the extension should be used by the
introduction point to learn what values the denial of service
subsystem should be using.
Perhaps we can name it "rate-limiting parameters"? But no strong opinion.
The EXT_FIELD content format is:
N_PARAMS[1 byte]
N_PARAMS times:
PARAM_TYPE [1 byte]
PARAM_VALUE [8 byte]
The PARAM_TYPE proposed values are:
[01] -- DOS_INTRODUCE2_RATE_PER_SEC
The rate per second of INTRODUCE2 cell relayed to the service.
[02] -- DOS_INTRODUCE2_BURST_PER_SEC
The burst per second of INTRODUCE2 cell relayed to the service.
The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values
(uint64_t). It MUST match the specified limit for the following PARAM_TYPE:
[01] -- Min: 0, Max: INT_MAX
[02] -- Min: 0, Max: INT_MAX
How would this new addition to the cell impact the size of the cell? How
much free space do we have for additional features to this cell (e.g. to
do the PoW stuff of the other thread)?
A value of 0 means the defense is disabled which has precedence over the
network wide consensus parameter.
In this case, if the rate per second is set to 0 (param 0x01) then the
burst value should be ignored. And vice-versa, if the burst value is 0,
then the rate value should be ignored. In other words, setting one single
parameter to 0 disables the INTRODUCE2 rate limiting defense.
I think it could be cool to add a discussion section where we introduce
a new cell from the intro to the service which informs the service that
rate limiting limits have been hit. So that there is a way for the
service to get feedback that it's under attack or capped by
limits. Otherwise, there is simply no way to learn it.
This can be a later feature fwiw.
3. Protocol Version
We introduce a new protocol version in order for onion service that wants
to specifically select introduction points supporting this new extension.
But also, it should be used to know when to send this extension or not.
The new version for the "HSIntro" protocol is:
"5" -- support ESTABLISH_INTRO cell DoS parameters extension for onion
service version 3 only.
4. Configuration Options
We also propose new torrc options in order for the operator to control
those values passed through the ESTABLISH_INTRO cell.
"HiddenServiceEnableIntroDoSDefense 0|1"
If this option is set to 1, the onion service will always send to the
introduction point denial of service defense parameters regardless of
what the consensus enables it or not. The value will be taken from
the consensus and if not present, the default values will be used.
(Default: 0)
"HiddenServiceEnableIntroDoSRatePerSec N sec"
Controls the introduce rate per second the introduction point should
impose on the introduction
Re: [tor-dev] Onion Service - Intropoint DoS Defenses
Ok, thanks, I was actually thinking about PoW on the Introduction Point itself, but it would need to add a round trip, like some sort of "authentication based PoW" before allowing to send the INTRODUCE1 cell. At least it would make the overhead of clients higher than I.P. as the clients would need to compute the PoW function and the I.P. only to verify it. So if right now the cost of the attack is "low" we can add an overhead of +10 to the client and only +2 to the I.P. (for example) and the hidden service doesn't need to do anything. I will write down my idea and send it here. On 31/5/19 20:26, Roger Dingledine wrote: On Thu, May 30, 2019 at 09:03:40PM +0200, juanjo wrote: And just came to my mind reading this, that to stop these attacks we could implement some authentication based on Proof of Work or something like that. This means that to launch such an attack the attacker (client level) should compute the PoW and must have many computing power, while normal clients/users don't need almost any change. Actually this is what PoW is very useful. Check out https://bugs.torproject.org/25066 for more details on this idea. There are still some interesting design questions to be resolved before it's really a proposed idea. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Onion Service - Intropoint DoS Defenses
Hello, can someone answer some questions I have about how this attacks work? As far as I understand INTRODUCE2 cells are sent by Introduction Points directly to the Hidden Service. But this only happens after a Client sends the INTRODUCE1 cell to the Introduction Point. Now the question is, do we allow more than 1 INTRODUCE1 per client circuit? If this is right, why? Or the attack is working because the client makes a new circuit/connection to the I.P. each time for sending a INTRODUCE1? On 31/5/19 14:21, David Goulet wrote: On 31 May (00:46:56), teor wrote: Hi, On 30 May 2019, at 23:49, David Goulet wrote: Over the normal 3 intro points a service has, it means 150 introduction per-second are allowed with a burst of 600 in total. Or in other words, 150 clients can reach the service every second up to a burst of 600 at once. This probably will ring alarms bell for very popular services that probably gets 1000+ users a second so please check next section. Do we know how many introduce cells are sent to popular services? How can the operators of these services find out their current introduce rate? Yes good point. The only thing we have available is the heartbeat that should read like so: log_notice(LD_HEARTBEAT, "Our onion service%s received %u v2 and %u v3 INTRODUCE2 cells " "and attempted to launch %d rendezvous circuits.", num_services == 1 ? "" : "s", hs_stats_get_n_introduce2_v2_cells(), hs_stats_get_n_introduce2_v3_cells(), hs_stats_get_n_rendezvous_launches()); Those counters don't get reset so to get the rate one need to compare between two heartbeats (default is every 6h). Thus, if any big popular service out there (no need to give the .onion) can tell us the rate they see, it would be grand! Thanks! David ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Onion Service - Intropoint DoS Defenses
Nice to try to stop this DoS vulnerability at network design level. Can we have an estimation of when will be released this antiDoS features? 0.4.1.x or 0.4.2.x ? And just came to my mind reading this, that to stop these attacks we could implement some authentication based on Proof of Work or something like that. This means that to launch such an attack the attacker (client level) should compute the PoW and must have many computing power, while normal clients/users don't need almost any change. Actually this is what PoW is very useful. On 30/5/19 15:49, David Goulet wrote: Greetings! As some of you know, a bunch of onion services were or are still under heavy DDoS on the network. More specifically, they are bombarded with introduction requests (INTRODUCE2 cells) which forces them to rendezvous for each of them by creating a ton of circuits. This basically leads to a resource exhaustion attack on the service side with its CPU massively used for path selection, opening new circuits and continously handling INTRODUCE2 cells. Unfortunately, our circuit-level flow control does not apply to the service introduction circuit which means that the intro point is allowed, by the Tor protocol, to send an arbitrary large amount of cells down the circuit. This means for the service that even after the DoS has stopped, it would still receive massive amounts of cells because some are either inflight on the circuit or queued at the intro point ready to be sent (towards the service). That being all said, our short-term goal here is to add INTRODUCE2 rate-limiting (similar to the Guard DoS subsystem deployed early last year) *at* the intro point but much simpler. The goal is to soak up the introduction load directly at the intro points which would help reduce the load on the network overall and thus preserve its health. Please have a look at https://trac.torproject.org/15516 for some discussions and ongoing code work. We are at the point where we have a branch that rate limits INTRODUCE2 cells at the intro point but we need to figure out proper values for the rate per second and the burst allowed. One naive approach is to see how much cells an attack can send towards a service. George and I have conducted experiment where with 10 *modified* tor clients bombarding a service at a much faster rate than 1 per-second (what vanilla tor does if asked to connect a lot), we see in 1 minute ~15000 INTRODUCE2 cells at the service. This varies in the thousands depending on different factors but overall that is a good average of our experiment. This means that 15000/60 = 250 cells per second. Considering that this is an absurd amount of INTRODUCE2 cells (maybe?), we can put a rate per second of let say a fifth meaning 50 and a burst of 200. Over the normal 3 intro points a service has, it means 150 introduction per-second are allowed with a burst of 600 in total. Or in other words, 150 clients can reach the service every second up to a burst of 600 at once. This probably will ring alarms bell for very popular services that probably gets 1000+ users a second so please check next section. I'm not that excited about hardcoded network wide values so this is why the next section is more exciting but much more work for us! One step further: we have not really decided yet if this is something we want nor have time to tackle but an idea here would be for a service to inform the intro point, using the ESTABLISH_INTRO cell payload, on the parameters it wants for its DoS defenses. So let say a very popular .onion with OnionBalance and 10 intro points, could tell to its intro points that it wants much higher values for the DoS defenses (or even put it off). However, it doesn't change the initial building block of being able to rate limit at the introduction point. As a second step, we can add this new type of ESTABLISH_INTRO cell. It is always dicy to introduce a new cell since for instance this would leak information to the intro point that the service is ">= version". Thus, this needs to be done with carefully. Time for your thoughts and help! :) Thanks everyone! David ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor exit bridges
Tor relays are public and easily blocked by IP. To connect to Tor network users where Tor is censored have to use bridges and even PTs. But, what happens on the exit? Many websites block Tor IPs so using it to access "clearweb" is not possible. Should we allow and start using "exit bridges"? In I2P we have not this problem since there is no central IP list of relays. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Sandboxed Tor Browser should be officially developed
I do not understand why Sandboxed Tor Browser is now deprecated when it should be the new thing in security features. It works well and stopped already some 0days in the past and today I see that not only is officially "*WARNING: Active development is on indefinite hiatus"* (https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux), the last commit is from 3 months ago, but still it works well. And today I see that for the Firefox 60 ESR this support will be removed (https://gitweb.torproject.org/builders/tor-browser-build.git/commit/?id=dc355882e235178d0a1889a7d96c5721faad2716). Is there a hidden agenda to allow LEA/governments to exploit Tor Browser users easily? Because I don't think maintaining the sandboxed version is that much work and it is a great protection for many users. So please, make Sandboxed Tor Browser an official thing. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Enhancement for Tor 0.3.4.x
If its just a wishlist I would love to see 1. More multithreading for Tor. 2. new technology against traffic correlation/confirmation attacks by adding some mixing features like I said long ago: Relay operators with great RAM set the flag mixing for their relays. These relays could be used as normal or mixing relays (delaying packets, mixing them and sending more noise data maybe?). Tor clients will have to specify if they want to build a normal circuit connection (fast) or a mixing connection, slow, but more anonymous. 3. a config value for forbidding that all nodes in a circuit be from the same country (to make traffic analysis harder..., some countries like UK seems to be using it already). 4. An easy way for people to setup a home relay from their computer? For Windows users? As more and more users get access to Fiber with symmetric speed, the slow speed and asymmetric problem is not here anymore. IDK. El 12/02/18 a las 20:32, David Goulet escribió: > Hello everone! > > As an effort to better organize our 0.3.4.x release for which the merge window > opens in 3 days (Feb 15th, 2018), we need to identify the enhancement(s) that > we want so we can better prioritize the development during the merge window > timeframe (3 months). > > Each feature should have its ticket marked for 0.3.4 milestone and with an > Owner set so we know who is "leading" that effort. It doesn't have to be the > person who code the whole thing but should be a good point of contact to start > with (and it can change over time as well). > > It is possible that an enhancement can have more than one ticket so in this > case, please make a "parent" ticket that explains the whole thing and child > tickets assigned to it. > > The network team just had its weekly meeting and if I recall correctly, these > enhancement should be planned for 0.3.4 (please the people who works on this, > can you tell us the tickets and make sure they are up to date?) > > - Privcount (prop#280) > - large CREATE cells (prop#249) > > If you plan to do a set of patches for a feature or enhancement, please do > submit it on this thread and make sure a proper ticket exists with an Owner. > > Also, if you just want something in 0.3.4 as enhancement but might not work on > it, it is also OK to propose it (ticket and all) but please lets try as much > as possible to keep that thread focused on doable work with tickets and not > just a "dump all my tor wishes" :). For this, open a ticket :). > > Big thanks everyone! > David > > > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Relays on Whonix Gateway
Interesting... I thought that a Tor client running a relay would actually help its privacy because you can't tell if its a client connection or relay connection... El 17/10/2016 a las 3:04, teor escribió: On 7 Oct 2016, at 08:11, ban...@openmailbox.org wrote: Should Whonix document/encourage end users to turn clients into relays on their machines? Probably not: * it increases the attack surface, * it makes their IP address public, * the relays would be of variable quality. Why not encourage them to run bridge relays instead, if their connection is fast enough? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
