wiki:org/sponsors/SponsorR/Reachability

Issues that can affect HS reachability

Current Issues

Past Issues

#13698: Wrong failure report when closing parallel intro points

The Tor client was wrongly flagging valid introduction points which makes it them unusable for at least 15 minutes which could potentially make the client stall on trying to reach an HS after multiple attempts/connections.

  • Introduced: Mon Jan 14 18:52:42 2013 -0500 commit: 3458d904f62b2d97dce5fea6f85285ea34851724 tag: 0.2.4.8-alpha
  • Fixed: Wed Dec 31 13:09:09 2014 -0500 commit: 6cb1daf062df525224ee7e3f7cd63ee858aacf9f release: tor-0.2.6.2-alpha

#15515: Don't allow multiple INTRODUCE1s on the same circuit

An introduction point could accept a large amount of INTRODUCE1 cells on one single circuit from a client basically DoSing an hidden service making it unavailable.

  • Introduced: <never introduced>
  • Fixed: Wed Apr 1 14:33:09 2015 +0100 commit: 8dba8a088d7c1402831ab5a7211a4a347a60ff7a release: tor-0.2.4.27, 0.2.5.x, 0.2.6.y ?

#15850: Don't assign HSDir flag to relay that can't handle BEGIN_DIR

Directory Authorities were voting the HSDir flag for relays without a DirPort but relays reject HSDir requests if they don't have a DirPort defined. This made ~35% HSDir unusable thus slowing down client connections to it by potentially making the client do more HS descriptor fetches.

#8902: Rumors that hidden services have trouble scaling to 100 concurrent connections

Summary: If an onion service has more than 100 users accessing it at the same time, it may respond slowly or not at all.

Despite the name, there are strong indications that this is the case for some relays. In the hidden service's logs, there will be blocks of tell-tale warnings:

[warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service blah.
[warn] Couldn't relaunch rendezvous circuit to '[scrubbed]'.

teor reports that he can induce a chutney-based onion service simulation to begin failing with 60 simulated users.

#15937: Clients fail on the 7th rapid SOCKS request to the same HS

Summary: If a client performs a SOCKS request 7 times without waiting for the past 6 requests to complete, then all 7 requests will fail.

  • Introduced: Unknown
  • Fixed: commit: d8b93b31a044be12778f9d7dcd9e4dd666db85e0 release: tor-0.2.8.2-alpha

#16052: Hidden service socket exhaustion by opening many connections

Summary: A denial of service attack can be conducted by sending thousands of RELAY_BEGIN packets to the onion service.

  • Introduced: <never introduced>
  • Fixed: commit: db7bde08be59398488624bc377d1d5318182ee45 release: tor-0.2.7.2-alpha

#16381: Bad timestamp check when storing an HS descriptor on the client

Summary: Tor shouldn't rely on the timestamp for HS descriptors, because the timestamp is rounded down to the nearest hour (thus any change in that time period will never be seen by the client). Rarely, this causes that hidden service to be unreachable by that client for the next hour.

If an HS restarts or published a new descriptor in a timeframe of 1 hour, the client that has already a descriptor for that HS won't be able to use the new descriptor in that same 1 hour due to a bad check of timestamp. This basically makes the HS unreachable for a period of 1 hour (or RendPeriod set on the HS).

  • Introduced: Sun Jan 18 15:39:12 2015 -0500 commit: 9407040c592184e05e45a3c1a00739c2dd302288 release: tor-0.2.6.3-alpha
  • Fixed: commit: 8acf5255c20c667f32313ee672c85f6ae00a4f87 release: tor-0.2.6.10
Last modified 20 months ago Last modified on Mar 23, 2016, 7:40:21 PM