nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-09-21 05:26:20 +02:00
Code Issues Packages Projects Releases Wiki Activity
mirror repository of the tor core protocol in case of issues
36,836 Commits 53 Branches 629 Tags 108 MiB
C 94.4%
Python 1.5%
C++ 1.1%
Shell 1.1%
M4 0.9%
Other 0.8%
218f9f90fb
Go to file
David Goulet 218f9f90fb guard: Don't check bridge transport name when selecting eligible guards 
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 09c6d03246 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 <dgoulet@torproject.org>
2021-04-08 14:08:28 -04:00
changes guard: Don't check bridge transport name when selecting eligible guards 2021-04-08 14:08:28 -04:00
contrib Bump version to 0.4.5.7-dev 2021-03-16 09:18:27 -04:00
doc Fix documentation formatting for VirtualAddrNetworkIPv6 2021-03-08 11:17:24 -05:00
m4 Fix typos. 2020-11-12 11:44:09 -05:00
scripts Merge branch 'maint-0.4.4' into maint-0.4.5 2021-02-05 17:40:25 +00:00
src guard: Don't check bridge transport name when selecting eligible guards 2021-04-08 14:08:28 -04:00
.appveyor.yml CI: Remove VS2015 AppVeyor build 2020-08-12 14:09:32 +03:00
.clang-format Add a dire warning about not reformatting the whole codebase yet. 2020-02-12 18:52:35 -05:00
.editorconfig Add .editorconfig to follow coding standards style 2018-06-17 19:24:40 -04:00
.gitignore Merge branch 'maint-0.4.3' into maint-0.4.4 2021-01-21 16:18:43 -05:00
.gitlab-ci.yml Fix typos. 2020-11-12 11:44:09 -05:00
.gitmodules Update the .gitmodules to refer to project-level tor-rust-dependencies 2018-02-21 11:53:04 -05:00
.travis.yml Add test for torrc %include functionality and seccomp sandbox 2020-07-15 22:01:08 +01:00
acinclude.m4 m4: Change LIBS order of TOR_SEARCH_LIBRARY() 2021-01-13 09:52:10 -05:00
autogen.sh Cleanup shellcheck warnings in autogen.sh 2019-01-18 13:49:30 +02:00
ChangeLog Correct EOL date for 0.4.3.x 2020-11-12 09:42:54 -05:00
CODE_OF_CONDUCT Add CODE_OF_CONDUCT file 2018-07-05 11:22:33 +03:00
config.rust.in Make the rust tests link. 2018-07-31 19:46:00 -04:00
configure.ac Bump version to 0.4.5.7-dev 2021-03-16 09:18:27 -04:00
CONTRIBUTING Add CODE_OF_CONDUCT file 2018-07-05 11:22:33 +03:00
Doxyfile.in Add correct exclusions to Doxyfile.in. 2020-07-07 10:24:24 -04:00
INSTALL Remove old instructions from INSTALL 2018-07-03 16:34:52 +03:00
LICENSE Merge branch 'maint-0.3.5' into maint-0.4.4 2021-03-12 11:36:34 -05:00
Makefile.am Merge branch 'maint-0.4.4' into maint-0.4.5 2021-01-21 16:07:16 -05:00
Makefile.nmake Clean up the MVSC nmake files so they work again. 2014-09-09 10:27:05 -04:00
README Use correct URL for CoreTorReleases in README. 2020-08-11 18:43:33 -04:00
ReleaseNotes Correct EOL date for 0.4.3.x 2020-11-12 09:42:54 -05:00
warning_flags.in Try @warning_flags to avoid bloating verbose make logs 2018-12-21 10:00:23 -05:00

README 

Tor protects your privacy on the internet by hiding the connection
between your Internet address and the services you use. We believe Tor
is reasonably secure, but please ensure you read the instructions and
configure it properly.

To build Tor from source:
        ./configure && make && make install

To build Tor from a just-cloned git repository:
        sh autogen.sh && ./configure && make && make install

Home page:
        https://www.torproject.org/

Download new versions:
        https://www.torproject.org/download/download.html

Documentation, including links to installation and setup instructions:
        https://www.torproject.org/docs/documentation.html

Making applications work with Tor:
        https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO

Frequently Asked Questions:
        https://www.torproject.org/docs/faq.html

Release timeline:
        https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases

To get started working on Tor development:
        See the doc/HACKING directory.