Changes between Version 5 and Version 6 of org/sponsors/SponsorR/Reachability


Ignore:
Timestamp:
Mar 23, 2016, 7:40:21 PM (3 years ago)
Author:
dgoulet
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • org/sponsors/SponsorR/Reachability

    v5 v6  
    11= Issues that can affect HS reachability =
    22== Current Issues ==
    3 '''#8902: Rumors that hidden services have trouble scaling to 100 concurrent connections'''
    4 
    5 Summary: ''If an onion service has more than 100 users accessing it at the same time, it may respond slowly or not at all.''
    6 
    7 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:
    8 
    9 {{{
    10 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service blah.
    11 [warn] Couldn't relaunch rendezvous circuit to '[scrubbed]'.
    12 }}}
    13 teor [https://trac.torproject.org/projects/tor/ticket/8902#comment:17 reports that he can induce] a chutney-based onion service simulation to begin failing with 60 simulated users.
    14 
    15 '''#15937: Clients fail on the 7th rapid SOCKS request to the same HS'''
    16 
    17 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.''
    18 
    19  * Introduced: Unknown
    20  * Fixed: Unknown
    21 
    22 '''#16052: Hidden service socket exhaustion by opening many connections'''
    23 
    24 Summary: ''A denial of service attack can be conducted by sending thousands of RELAY_BEGIN packets to the onion service.''
    25 
    26  * Introduced: <never introduced>
    27  * Fixed: ''commit'': db7bde08be59398488624bc377d1d5318182ee45 ''release'': <not released>
    28 
    29 
    30 
    31 '''#16381: Bad timestamp check when storing an HS descriptor on the client'''
    32 
    33 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.''
    34 
    35 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).
    36 
    37  * Introduced: Sun Jan 18 15:39:12 2015 -0500 ''commit'': 9407040c592184e05e45a3c1a00739c2dd302288 ''release'': tor-0.2.6.3-alpha
    38  * Fixed: ''commit'': 8acf5255c20c667f32313ee672c85f6ae00a4f87 ''release'': <not released>
    393
    404== Past Issues ==
     
    5923 * Introduced: Thu Jan 29 12:52:18 2015 -0500 commit: 80bed1ac96a3035f8c55ddced5528f0d7d16d386 release: tor-0.2.6.3-alpha
    6024 * Fixed: Tue Apr 28 14:22:49 2015 -0400 commit: 26c344a563610fcd293cd82bbb0b08dce737e5f3 release: tor-0.2.6.8
    61  * Affected Tor network from mid April 2015 to end of May 2015: https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-03-07&end=2015-07-06&flag=HSDir
     25 * Affected Tor network from mid April 2015 to end of May 2015: https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-03-07&end=2015-07-06&flag=HSDir'''
     26
     27#8902: Rumors that hidden services have trouble scaling to 100 concurrent connections'''
     28
     29Summary: ''If an onion service has more than 100 users accessing it at the same time, it may respond slowly or not at all.''
     30
     31Despite 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:
     32
     33{{{
     34[warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service blah.
     35[warn] Couldn't relaunch rendezvous circuit to '[scrubbed]'.
     36}}}
     37teor [https://trac.torproject.org/projects/tor/ticket/8902#comment:17 reports that he can induce] a chutney-based onion service simulation to begin failing with 60 simulated users.
     38
     39
     40'''#15937: Clients fail on the 7th rapid SOCKS request to the same HS'''
     41
     42Summary: ''If a client performs a SOCKS request 7 times without waiting for the past 6 requests to complete, then all 7 requests will fail.''
     43
     44 * Introduced: Unknown
     45 * Fixed: ''commit'': d8b93b31a044be12778f9d7dcd9e4dd666db85e0 ''release'': tor-0.2.8.2-alpha
     46
     47'''#16052: Hidden service socket exhaustion by opening many connections'''
     48
     49Summary: ''A denial of service attack can be conducted by sending thousands of RELAY_BEGIN packets to the onion service.''
     50
     51 * Introduced: <never introduced>
     52 * Fixed: ''commit'': db7bde08be59398488624bc377d1d5318182ee45 ''release'': tor-0.2.7.2-alpha
     53
     54'''#16381: Bad timestamp check when storing an HS descriptor on the client'''
     55
     56Summary: ''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.''
     57
     58If 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).
     59
     60 * Introduced: Sun Jan 18 15:39:12 2015 -0500 ''commit'': 9407040c592184e05e45a3c1a00739c2dd302288 ''release'': tor-0.2.6.3-alpha
     61 * Fixed: ''commit'': 8acf5255c20c667f32313ee672c85f6ae00a4f87 ''release'': tor-0.2.6.10