[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #14937 [Tor Browser]: Get meek working in Tor Circuit Display



#14937: Get meek working in Tor Circuit Display
--------------------------+------------------------------------------------
     Reporter:            |      Owner:  tbb-team
  arthuredelstein         |     Status:  needs_information
         Type:  defect    |  Milestone:
     Priority:  normal    |    Version:
    Component:  Tor       |   Keywords:  tbb-circuit-display, tbb-usability
  Browser                 |  Parent ID:
   Resolution:            |
Actual Points:            |
       Points:            |
--------------------------+------------------------------------------------

Comment (by dcf):

 Replying to [comment:12 arthuredelstein]:
 > Replying to [comment:10 dcf]:
 >
 > Is my understanding correct, that for each meek target bundled with Tor
 Browser, there is a single meek server with a unique, unchanging
 fingerprint? In that case, I could simply hard-code a list of these
 fingerprints. Does that make sense to you?

 It happens to currently be the case that each meek backend has a dedicated
 bridge with a unique fingerprint, but please do not rely on that. We have
 had to change them beforeâfor example, all of meek-google, meek-amazon,
 and meek-azure used to run over a single bridge, before we sitched them
 out to separate bridgesâand we wouldn't have had to do that without a
 lengthy deprecation period if we had hardcoded the single bridge's
 fingerprint in people's bundles.

 It's like what happened to some of the default obfs2 bridges a while back,
 when they were affected by Heartbleed. The operator generated new keys,
 but had to keep the old bridges running with the old keys for a long time,
 because there was no way to update clients with the old fingerprint
 hardcoded. With meek we have an extra layer of virtualization because the
 bridge line is not tightly coupled to the backing bridge.

 The first bridge hop (even for vanilla bridges) is really an untrusted,
 unauthenticated hop. That's the reason I think we should use four hops for
 bridge circuits. The first hop is a leap of faith, and then you choose and
 authenticate your next three hops. Check this old thread:
 https://lists.torproject.org/pipermail/tor-dev/2014-September/007511.html

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