1. 04 May, 2021 1 commit
  2. 30 Apr, 2021 5 commits
  3. 28 Apr, 2021 1 commit
    • Mike Perry's avatar
      Lower L2 rotation rate. · cab1930a
      Mike Perry authored
      This sets our rotation expectation to ~7days.
      
      Since Tor Browser updates 1x/mo, this is 4 rotations max before a tab is
      closed due to update. This puts us at ~10% success for 1% adversary, 50% for
      5%, and 75% for 10%, if the attack is in progress for an entire Tor Browser
      update cycle.
      cab1930a
  4. 27 Apr, 2021 1 commit
    • Mike Perry's avatar
      Use HS_VANGUARDS purpose for pre-built circs. · 2ac63db5
      Mike Perry authored
      Also ensure cannibalization works properly, and disables path restrictions for
      vanguards circuits as a result.
      
      Note that this change makes us use prop#247 pathlens even for vg-lite.
      It also fails a unittest for this reason.
      
      Once we decide on L2-only vs L2+L3, we should fix the unittest and
      routelen_for_purpose().
      2ac63db5
  5. 24 Apr, 2021 2 commits
  6. 23 Apr, 2021 1 commit
  7. 20 Apr, 2021 1 commit
  8. 15 Apr, 2021 2 commits
  9. 14 Apr, 2021 10 commits
  10. 13 Apr, 2021 10 commits
  11. 12 Apr, 2021 1 commit
  12. 08 Apr, 2021 4 commits
    • David Goulet's avatar
      guard: Don't check bridge transport name when selecting eligible guards · 218f9f90
      David Goulet authored
      This is related to ticket #40360 which found this problem when a Bridge entry
      with a transport name (let say obfs4) is set without a fingerprint:
      
        Bridge obfs4 <IP>:<PORT> cert=<...> iat-mode=0
      
      (Notice, no fingerprint between PORT and "cert=")
      
      Problem: commit 09c6d032
      
       added a check in
      get_sampled_guard_for_bridge() that would return NULL if the selected bridge
      did not have a valid transport name (that is the Bridge transport name that
      corresponds to a ClientTransportPlugin).
      
      Unfortuantely, this function is also used when selecting our eligible guards
      which is done *before* the transport list is populated and so the added check
      for the bridge<->transport name is querying an empty list of transports
      resulting in always returning NULL.
      
      For completion, the logic is: Pick eligible guards (use bridge(s) if need be)
      then for those, initiate a connection to the pluggable transport proxy and
      then populate the transport list once we've connected.
      
      Back to get_sampled_guard_for_bridge(). As said earlier, it is used when
      selecting our eligible guards in a way that prevents us from selecting
      duplicates. In other words, if that function returns non-NULL, the selection
      continues considering the bridge was sampled before. But if it returns NULL,
      the relay is added to the eligible list.
      
      This bug made it that our eligible guard list was populated with the *same*
      bridge 3 times like so (remember no fingerprint):
      
        [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is:
        [info] entry_guards_update_primary():   1/3: [bridge] ($0000000000000000000000000000000000000000)
        [info] entry_guards_update_primary():   2/3: [bridge] ($0000000000000000000000000000000000000000)
        [info] entry_guards_update_primary():   3/3: [bridge] ($0000000000000000000000000000000000000000)
      
      When tor starts, it will find the bridge fingerprint by connecting to it and
      will then update the primary guard list by calling
      entry_guard_learned_bridge_identity() which then goes and update only 1 single
      entry resulting in this list:
      
        [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($<FINGERPRINT>) is still listed.
        [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed.
        [debug] sampled_guards_update_consensus_presence(): Sampled guard [bridge] ($0000000000000000000000000000000000000000) is still listed.
      
      And here lies the problem, now tor is stuck attempting to wait for a valid
      descriptor for at least 2 guards where the second one is a bunch of zeroes and
      thus tor will never fully bootstraps:
      
        [info] I learned some more directory information, but not enough to build a
        circuit: We're missing descriptors for 1/2 of our primary entry guards
        (total microdescriptors: 6671/6703). That's ok. We will try to fetch missing
        descriptors soon.
      
      Now, why passing the fingerprint then works? This is because the list of
      guards contains 3 times the same bridge but they all have a fingerprint and so
      the descriptor can be found and tor can bootstraps.
      
      The solution here is to entirely remove the transport name check in
      get_sampled_guard_for_bridge() since the transport_list is empty at that
      point. That way, the eligible guard list only gets 1 entry, the bridge, and
      can then go on to bootstrap properly.
      
      It is OK to do so since when launching a bridge descriptor fetch, we validate
      that the bridge transport name is OK and thus avoid connecting to a bridge
      without a ClientTransportPlugin. If we wanted to keep the check in place, we
      would need to populate the transport_list much earlier and this would require
      a much bigger refactoring.
      
      Fixes #40360
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      218f9f90
    • George Kadianakis's avatar
      62614f0b
    • George Kadianakis's avatar
      Merge branch 'maint-0.4.5' · e0b8a79b
      George Kadianakis authored
      e0b8a79b
    • George Kadianakis's avatar
      b07ed22c
  13. 05 Apr, 2021 1 commit