Re: [tor-bugs] #12147 [BridgeDB]: BridgeDB bridge requests over HTTPS have another timeout issue

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

#12147: BridgeDB bridge requests over HTTPS have another timeout issue
-------------------------+-------------------------------------------------
     Reporter:  isis     |      Owner:  isis
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:
  critical               |    Version:
    Component:           |   Keywords:  bridgedb-0.2.2, security, bridgedb-
  BridgeDB               |  https
   Resolution:           |  Parent ID:
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by isis):

 Fixed in my `hotfix/11215_12147-intervalstart` branch. Deployed in version
 0.2.2.

 The commit message explains more about the nature and effect of this bug:

 {{{
     Call schedule.intervalStart() to get epoch for HTTPS bridge request.

     The ``epoch`` of a request is a value that is supposed to be the
     interval of time which the request occurred within, i.e. a request at
     14:18 is in the 10-minute interval of 14:10-14:20. This ``epoch`` is
     used to obtain bridges in response to a client's request,
 specifically,
     it's a parameter to the ``bridgedb.Dist.getBridgesForIP()`` method,
     which does all the real work.

     In implementation (up until a couple weeks ago), there was an odd
 thing
     in that a request's ``epoch`` was always hardcoded to be ``"1970"``. I
     changed the part which returns ``"1970"`` to return an ISO-8601
     timestamp, under the assumtion that anything asking for an interval
     would use the ``intervalStart()`` or ``nextIntervalStarts()`` methods
 to
     compare the curr ent timestamp to the interval it should reside
     within. My assumption was wrong; in
 ``bridgedb.Dist.getBridgesForIP()``,
     in the first line of that method, ``schedule.getInterval()`` is called
     instead. I had even made an XXX note a long time ago stating that this
     was a dumb thing to do. I forgot to change it. Oops.

     The fix is to change the first line of
     ``bridgedb.Dist.getBridgesForIP()`` from
 ``self.schedule.getInterval()``
     to ``self.schedule.intervalStarts()` `.  This was also preventing the
     CAPTCHA expiration from functioning correctly.

     After making this change, it exhibits the correct behaviour, which is,
     first, to only respond after determining that we're within the
 10-minute
     interval in which the CAPTCHA was issued, and second, determine if the
     solution to the CATPCHA is correct (and if so give the bridges that we
     would give to that IP address cluster, ignoring time intervals
     altogether).

      * FIXES #12147
      * THANKS to arma for forwarding to the original bug report to
        tor-assistants@xxxxxxxxxxxxxxxxxxxxx
      * THANKS TO Francisco on IRC for discovering and reporting the issue.
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12147#comment:1>
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