Changes between Initial Version and Version 3 of Ticket #20528


Ignore:
Timestamp:
Nov 2, 2016, 7:59:36 AM (3 years ago)
Author:
teor
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #20528

    • Property Keywords bridge-bypass removed
    • Property Summary changed from Defend against bridge bypass with misconfigured bridges to Make sure bridge clients update bridges when options are updated
    • Property Milestone changed from Tor: 0.3.0.x-final to Tor: 0.2.???
  • Ticket #20528 – Description

    initial v3  
    11Currently, we keep our consensus and guards and nodes, even after an options transition.
    22
    3 A user reports that this may bypass bridges when bridge fingerprints are misconfigured, and we switch between bridge client and regular client mode:
     3~~A user reports that this may bypass bridges when bridge fingerprints are misconfigured, and we switch between bridge client and regular client mode:
    44https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html
    5 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.
     5This 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.~~
    66
    77So we should reload the cached consensus, reset downloads and reconfigure guards after options transitions.