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

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

#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 arthuredelstein):

 Replying to [comment:13 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.

 What I had in mind is strictly for display in the UI, and wouldn't affect
 the ability to connect to servers with new fingerprints. On the other
 hand, it will be definitely much better to implement something like
 comment:7. For now I will leave this ticket unfixed until we find a robust
 solution.

 > 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

 It's an interesting point. Is there a ticket for this?

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