Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:28:06Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26806Check if Tor clients sometimes send duplicate cells on rendezvous circuits: P...2020-06-13T15:28:06Zs7rCheck if Tor clients sometimes send duplicate cells on rendezvous circuits: Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seenAs my v3 onion service is getting more and more popular, I started to get:
```
[warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 32 seconds ago. Dropping cell.
```
I am inclined to think that th...As my v3 onion service is getting more and more popular, I started to get:
```
[warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 32 seconds ago. Dropping cell.
```
I am inclined to think that this is more like a bug in Tor, maybe due to a race condition, rather than a replay attack.
I also think this is what causes #15618 - dgoulet confirmed that the warning can be reproduced every time a second `ESTABLISH_RENDEZVOUS` is sent over the same circuit.
This can probably go away if we fix #21084. I am not sure if that should be a parent ticket here or not, please change if you feel like it. I think I still have yawning's tool and notes about how to reproduce #21084.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26768Support onionbalance in HSv32020-06-13T15:27:55ZGeorge KadianakisSupport onionbalance in HSv3We are implementing onionbalance in v3! This is the master ticket.
[Description changed to not confuse people with the old design.]We are implementing onionbalance in v3! This is the master ticket.
[Description changed to not confuse people with the old design.]Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/25568hs: Lookup failure cache when introducing to an intro point2020-06-13T15:23:25ZDavid Gouletdgoulet@torproject.orghs: Lookup failure cache when introducing to an intro pointIt turns out that if a descriptor contains 10 times the same intro point, and that the first introduction attempt fails, we'll try to connect to the same failing intro point again for all subsequent remaining intro points.
The intro poi...It turns out that if a descriptor contains 10 times the same intro point, and that the first introduction attempt fails, we'll try to connect to the same failing intro point again for all subsequent remaining intro points.
The intro point failure cache was introduced to avoid such a situation but it is only used between two descriptors that is if an intro point failed from the first descriptor and that intro point is still present in the second descriptor fetched, we ignore it.
However, this situation is about the same intro point in the same descriptor. In normal circumstances, this can't happen but it is still allowed by the protocol.
One issue with this is that a malicious service would induce many circuits out of the client than necessary. This can be used, theoretically, for a client guard discovery attack.
This affects both v2 and v3.Tor: 0.4.3.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24963dos: Block single hop clients at the intro point2020-06-13T15:20:54ZDavid Gouletdgoulet@torproject.orgdos: Block single hop clients at the intro pointThis is so we remove load from spammy single hop clients at the Intro point.
Opened after discussion in #24902.
Lets consider this also as a possible backport.This is so we remove load from spammy single hop clients at the Intro point.
Opened after discussion in #24902.
Lets consider this also as a possible backport.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/3733Tor should abandon rendezvous circuits that cause a client request to time out2020-06-13T14:12:26ZRobert RansomTor should abandon rendezvous circuits that cause a client request to time out```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice...```
Aug 14 05:59:04.639 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 05:59:09.631 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:08.637 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:10.634 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
Aug 14 06:04:30.680 [Notice] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
```
All of these streams had been attached to the same rendezvous circuit.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31369HSv3 descriptor support in stem [decoding]2020-06-13T10:52:54ZGeorge KadianakisHSv3 descriptor support in stem [decoding]Hello,
it would be great if stem could support v3 onion service descriptors: both to parse them and to generate them.
This would be particularly useful as part of onionbalance v3 (#26768). The old onionbalance actually generates the de...Hello,
it would be great if stem could support v3 onion service descriptors: both to parse them and to generate them.
This would be particularly useful as part of onionbalance v3 (#26768). The old onionbalance actually generates the descriptors itself in an ad-hoc way, but it would be great if we could have stem make them in the new one.
Damian asked me for an HSFETCH command that will fetch a stable v3 onion desc. I used Donncha's script from here (https://gist.github.com/DonnchaC/13b744a1e30b7d34bc26) like this:
`python tmp/hsfetch.py vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion` and that gives me the riseup onion descriptor (there is no DDG v3 onion right now).
Also, v3 descriptors are more complicated than v2 descriptors because of their double-layer encryption. You can see more info here: https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt#L1046
https://github.com/torproject/tor/blob/0acfd7dcee2a4473eba05a53d6df2d6d4fe2050b/src/feature/hs/hs_descriptor.c#L2639
Damian, let me know how that looks like to you and how we can help. We plan to start working on Onionbalance v3 at mid-to-late August, but if this is something we can have at a reasonaable timeframe we can potentially delay the descriptor parts of it for some time until stem support exists.Damian JohnsonDamian Johnson