[tor-talk] I can't use Tor via "obfs3" or other methods.

[Cubed]

On Mon, 19 Oct 2015 00:05:49 +0000
isis <isis at torproject.org> wrote:


Aloha isis, 

Thanks for your input; you and I had the exact same thoughts on the
matter. I agree, it's odd, and I was wrong to assume the problem was a
hardware issue, ultimately. Some details that are relevant and were
left out of my original response: 

- Workstations, whether laptop of desktop (predominately laptops
  though), were all being used as Tails hosts. 
- The TBB, run in whatever nix flavor, and I even think weird OS's like
  Windows, was perfectly capable of running OBFS4 bridges. 

The workstations are not all physically in my reach and I have only
recently acquired a laptop that showed the problem. So once I was
finally able to control for the above variables, I found that, if
anything, it's a Tails-centric issue. 

The problem was replicatable on a variety of public and private
networks. Ultimately, I don't think the ISPs had anything to do with
it; it's not a censorship issue as far as I can tell. Based on where
it hangs, and the eventual work around I figured out, I think the
problem might have something to with building the initial Tor
directory. I almost feel like writing that as a question, to
communicate that I have not grokked the entire Tor circuit building
routine. 

But, in every case, OBFS3 bridges worked. So eventually I tossed in
one OBFS3 bridge along with a few OBFS4. Voila, Tor directory builds
off the OBFS3 bridge (as it appears in the logs and through viewing
the network map), and OBFS4 bridges are utilized immediately after.
Cancel the OBFS3 connection, and nothing changes; so the OBFS3 bridge
just needed to be there for the initial circuit building. 

And, if the Tails drive has persistence enabled with network
configuration saved, the problem seems to eventually stop altogether. 

Personally, I'm surprised practically no one else has reported similar
experiences (I follow the tails mailing list as well). It would seem to
me that Tails is doing something different than the TBB that results in
the bug. Which is plausible; Tails still uses Vidalia, which was
deprecated elsewhere a while back. Vidalia, in Tails, is basically a
hack that acts as an abstraction layer between the user and her torrc.
Also, while OBFS4 sounds like the latest version of OBFS, implying that
the two protocols are similar, 3 and 4 are actually quite different. 4
being closer to scramblesuit or something. 

Anyways, I've contributed the experience, I hope it saves someone an
hour or two and helps them gain a pint or three! I gotta get back to
figuring out how this baffling Windows registry works...

3



> Cubed transcribed 6.4K bytes:
> > On Wed, 30 Sep 2015 18:12:11 +0000 (UTC)
> > Jason Long <hack3rcon at yahoo.com> wrote:
> > 
> > 
> > First, sorry for the thread necromancy. Thought it was worth
> > responding too, though, since the OP didn't get much of an answer.
> > 
> > Second, hello Jason, I have been experimenting with various
> > configurations and OBFS3/4 compatibility. I first noticed problems
> > connecting to OBFS4 bridges while using Tails on an older ASUS
> > laptop. I thought it was an outlier until I found several other
> > laptop models that had similar issues with almost identical logs to
> > yours. 
> > 
> > I still don't know exactly what inhibits a network interface from
> > connecting to a bridge but do have some info that might help push
> > the issue forward and give you connectivity. Also, as you probably
> > inferred, I believe it has to do with the network device the laptop
> > or computer is using to connect. 
> > 
> > "iwlwifi" is a driver that has been part of debian stable for a long
> > time, AFAIK. This is the driver that a ton of laptops will assign to
> > the network interface. But on most newer lenovo's and some other
> > models, a different driver is used and with those laptops, OBFS4 and
> > sometimes OBFS3 will never connect. 
> > 
> > My troubleshooting steps have been as follows:
> > - Try connecting to OBFS4
> > - Try connecting to OBFS3
> > - Try both 3/4 but with only <obfs* {ip_address:port}
> > {fingerprint}>, and not including the cert, etc. 
> > - Try using a different interface like a USB wifi device, I've had
> >   positive results with most ralink chipsets.
> > - Try a direct ethernet connection.
> > 
> > I thought that the problem had something to do with how tails clones
> > are made but now I'm unconvinced this is a problem. If you connect
> > to tor via some other setup, these suggestions should help. 
> > 
> > In most of the configs I've worked on, ethernet has provided me at
> > least OBFS3 connectivity. In another case, the user needed to
> > include at least 1 OBFS3 bridge and all the bridges would connect
> > and work, but if she used all OBFS4, tor directory would never
> > download. 
> > 
> > Hope this helps.
> > three 
> 
> Hey three,
> 
> Nothing happening at the network interface level should be capable of
> affecting the functionality of either obfs3 or obfs4.  It sounds to
> me like you might be having some issue with your local router setup,
> like perhaps a NAT table messing something up somewhere, based on you
> statements that using ethernet had better luck that using wifi.  I
> can't really imagine any way that a censor would be able to determine
> whether you're using ethernet/wifi and censor your connections
> differently based upon said information.  (If they can do this, then
> something is horribly, horribly wrong with your wifi router!)
> 
> Best of luck,