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
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
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
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
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.
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
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
dea 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 l
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,
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
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"?
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"*
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
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
14 matches
Mail list logo
