[tor-bugs] #28655 [Obfuscation/BridgeDB]: If a bridge supports obfs4, don't give out its other flavors

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Apr 15 18:43:37 UTC 2019


#28655: If a bridge supports obfs4, don't give out its other flavors
----------------------------------+------------------------------
 Reporter:  arma                  |          Owner:  phw
     Type:  defect                |         Status:  needs_review
 Priority:  High                  |      Milestone:
Component:  Obfuscation/BridgeDB  |        Version:
 Severity:  Normal                |     Resolution:
 Keywords:  bridgedb              |  Actual Points:
Parent ID:                        |         Points:  2
 Reviewer:                        |        Sponsor:  Sponsor19
----------------------------------+------------------------------

Comment (by phw):

 So far, all of leekspin's generated descriptors included obfs2, obfs3,
 obfs4, and scramblesuit. This broke BridgeDB's unit tests because all
 descriptors included a probing-resistant PT (obfs4 and scramblesuit), so
 BridgeDB wouldn't hand out its obfs2, obfs3, and vanilla bridges. To fix
 this, I made leekspin generate descriptors with various combinations of
 pluggable transports:
 https://gitweb.torproject.org/user/phw/leekspin.git/commit/?id=9af6c71b3b4aeb56c509df9ae6a16650f9b58dd2
 Let me know if this patch looks good to you.

 Unfortunately, the HTTPS unit tests still break -- apparently randomly.
 Here's one of my recent, failed builds: https://travis-
 ci.org/NullHypothesis/bridgedb/jobs/520411314

 Since my leekspin patch creates pluggable transport combinations
 deterministically, I believe that the issue is somewhere in BridgeDB's
 HTTPS distribution mechanism.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28655#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list