Re: [tor-bugs] #20528 [Core Tor/Tor]: Make sure bridge clients update bridges when options are updated (was: Defend against bridge bypass with misconfigured bridges)

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#20528: Make sure bridge clients update bridges when options are updated
---------------------------+------------------------------
 Reporter:  teor           |          Owner:
     Type:  defect         |         Status:  new
 Priority:  Medium         |      Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor   |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  bridge-client  |  Actual Points:
Parent ID:                 |         Points:  1
 Reviewer:                 |        Sponsor:
---------------------------+------------------------------
Changes (by teor):

 * keywords:  bridge-client, bridge-bypass => bridge-client


Old description:

> Currently, we keep our consensus and guards and nodes, even after an
> options transition.
>
> A user reports that this may bypass bridges when bridge fingerprints are
> misconfigured, and we switch between bridge client and regular client
> mode:
> https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html
> This bypass is likely timing-related - I suspect it only occurs if tor
> tries a connection to the bridge before the new bridges and pluggable
> transports are properly configured.
>
> So we should reload the cached consensus, reset downloads and reconfigure
> guards after options transitions.
>
> Conceptually, we want to do something like:
> (it currently doesn't work due to assertions, so we probably want to
> conditionalise parts of it on has_reasonably_live_consensus() or
> something)
> {{{
> diff --git a/src/or/config.c b/src/or/config.c
> index fef1208..4ecf0ba 100644
> --- a/src/or/config.c
> +++ b/src/or/config.c
> @@ -1183,6 +1183,13 @@ consider_adding_dir_servers(const or_options_t
> *options,
>    for (cl = options->FallbackDir; cl; cl = cl->next)
>      if (parse_dir_fallback_line(cl->value, 0)<0)
>        return -1;
> +
> +  /* Reset the consensus, because the authorities might have changed */
> +  time_t now = time(NULL);
> +  networkstatus_reset_warnings();
> +  router_reload_consensus_networkstatus();
> +  routerlist_retry_directory_downloads(now);
> +
>    return 0;
>  }
>
> @@ -1889,6 +1896,11 @@ options_act(const or_options_t *old_options)
>        circuit_mark_all_unused_circs();
>        circuit_mark_all_dirty_circs_as_unusable();
>        revise_trackexithosts = 1;
> +
> +      /* And reload the consensus, which also updates guards (and
> bridges) */
> +      time_t now = time(NULL);
> +      router_reload_consensus_networkstatus();
> +      routerlist_retry_directory_downloads(now);
>      }
>
>      if (!smartlist_strings_eq(old_options->TrackHostExits,
> }}}

New description:

 Currently, we keep our consensus and guards and nodes, even after an
 options transition.

 ~~A user reports that this may bypass bridges when bridge fingerprints are
 misconfigured, and we switch between bridge client and regular client
 mode:
 https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html
 This bypass is likely timing-related - I suspect it only occurs if tor
 tries a connection to the bridge before the new bridges and pluggable
 transports are properly configured.~~

 So we should reload the cached consensus, reset downloads and reconfigure
 guards after options transitions.

 Conceptually, we want to do something like:
 (it currently doesn't work due to assertions, so we probably want to
 conditionalise parts of it on has_reasonably_live_consensus() or
 something)
 {{{
 diff --git a/src/or/config.c b/src/or/config.c
 index fef1208..4ecf0ba 100644
 --- a/src/or/config.c
 +++ b/src/or/config.c
 @@ -1183,6 +1183,13 @@ consider_adding_dir_servers(const or_options_t
 *options,
    for (cl = options->FallbackDir; cl; cl = cl->next)
      if (parse_dir_fallback_line(cl->value, 0)<0)
        return -1;
 +
 +  /* Reset the consensus, because the authorities might have changed */
 +  time_t now = time(NULL);
 +  networkstatus_reset_warnings();
 +  router_reload_consensus_networkstatus();
 +  routerlist_retry_directory_downloads(now);
 +
    return 0;
  }

 @@ -1889,6 +1896,11 @@ options_act(const or_options_t *old_options)
        circuit_mark_all_unused_circs();
        circuit_mark_all_dirty_circs_as_unusable();
        revise_trackexithosts = 1;
 +
 +      /* And reload the consensus, which also updates guards (and
 bridges) */
 +      time_t now = time(NULL);
 +      router_reload_consensus_networkstatus();
 +      routerlist_retry_directory_downloads(now);
      }

      if (!smartlist_strings_eq(old_options->TrackHostExits,
 }}}

--

Comment:

 It might not explain your issue, but it is still a bug.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20528#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs