[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18517 [Tor]: meek is broken in Tor Browser 6.0a3
#18517: meek is broken in Tor Browser 6.0a3
-------------------------------------------------+-------------------------
Reporter: gk | Owner: tbb-
Type: defect | team
Priority: Very High | Status:
Component: Tor | needs_review
Severity: Normal | Milestone: Tor:
Keywords: regression must-fix-before-028-rc | 0.2.8.x-final
meek | Version: Tor:
Parent ID: | 0.2.8.1-alpha
Reviewer: | Resolution:
| Actual Points:
| Points:
| Sponsor: None
-------------------------------------------------+-------------------------
Comment (by teor):
Replying to [comment:8 yawning]:
> Replying to [comment:7 teor]:
> > I think what tor should do is:
> > * if a transport is specified in the Bridge line, and that transport
corresponds to a ClientTransportPlugin line, tor should pass the address
in the bridge line to the pluggable transport, and not try to connect to
that address itself. (The pluggable transport is free to use [obfsproxy]
or ignore [meek] that address.)
>
> This is what it used to do before it changed it, the "decide if need to
pass it onto a PT" is done at the last possible moment. What your code
change effectively does is add "before passing the address to the PT (if
applicable), check that it is not internal" (See:
connection_or.c:`connection_or_connect()`).
>
> This change also breaks normal (non-PT) bridges hosted on an internal
network, but I'm not sure if that's a common use case for actual users.
It's rather common for me to run a bridge on the same host (communicating
over the loopback interface) for testing, but I only need to edit 15 or so
torrc files....
>
> The solutions I can think of off the top of my head are:
>
> * Allow connections to *all* bridges on "internal addresses".
I think allowing bridges on internal addresses is a good fix for this.
(And since they're configured in the torrc, this doesn't open any security
holes. Bridge addresses can be updated from bridgedb, but if bridgedb
started returning broken addresses, then that's not an issue clients can
defend against.)
Please see my branch bug18517 at https://github.com/teor2345/tor.git
It fixes this issue and clarifies the corresponding entries in the tor man
page.
It needs to go in tor-0.2.8-rc, target date end of March.
dcf, sorry that I've flipped this issue from tor to tor browser and back.
Which one do you want to make a separate ticket for?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18517#comment:12>
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