Re: [tor-dev] Why is my bridge not publishing statistics?
On Sat, May 06, 2017 at 09:25:11AM -0700, David Fifield wrote: > > You're right that this is a fragile situation. Maybe we should recommend > > that if you firewall your ORPort, you also set "AssumeReachable 1" > > in your torrc? > > I've just set "AssumeReachable 1"; let's see if that helps anything. Setting "AssumeReachable 1" seems to have worked. https://atlas.torproject.org/#details/5481936581E23D2D178105D44DB6915AB06BFB7F ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Why is my bridge not publishing statistics?
On Sat, May 06, 2017 at 03:41:28AM -0400, Roger Dingledine wrote: > On Fri, May 05, 2017 at 04:30:52PM -0700, David Fifield wrote: > > But if it's the case that an unreachable ORPort causes descriptors not > > to be uploaded, then why do the default obfs4 bridges appear in Atlas? > > Tor relays (and bridges) test their reachability by making circuits > that loop back to themselves, and they consider themselves reachable > when an incoming connection sends a create cell (see the end of > onionskin_answer()). > > You might think that these two actions are more connected, i.e. that > it needs to be one of the loop circuits that sends the create cell, > but no, they're completely disconnected. So the relay (or bridge) > can launch all the loop circuits it wants, and they can all fail, but > if something causes an incoming connection that sends a create cell, > it will happily conclude that it's reachable. > > So it's likely that the reason the default bridges are publishing to > the bridge authority is because somebody used them via obfs4, at which > point they decided they were reachable, at which point they decided it > was cool to publish. Okay, thanks. It still doesn't fully make sense to me, because while some of the default bridges are in Atlas, not all of them are (for example the two from https://bugs.torproject.org/18050). I don't think it's possible that they haven't gotten *any* client traffic. I wonder if it has something to do with the tor version number? > You're right that this is a fragile situation. Maybe we should recommend > that if you firewall your ORPort, you also set "AssumeReachable 1" > in your torrc? I've just set "AssumeReachable 1"; let's see if that helps anything. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Why is my bridge not publishing statistics?
On Fri, May 05, 2017 at 04:30:52PM -0700, David Fifield wrote: > But if it's the case that an unreachable ORPort causes descriptors not > to be uploaded, then why do the default obfs4 bridges appear in Atlas? Tor relays (and bridges) test their reachability by making circuits that loop back to themselves, and they consider themselves reachable when an incoming connection sends a create cell (see the end of onionskin_answer()). You might think that these two actions are more connected, i.e. that it needs to be one of the loop circuits that sends the create cell, but no, they're completely disconnected. So the relay (or bridge) can launch all the loop circuits it wants, and they can all fail, but if something causes an incoming connection that sends a create cell, it will happily conclude that it's reachable. So it's likely that the reason the default bridges are publishing to the bridge authority is because somebody used them via obfs4, at which point they decided they were reachable, at which point they decided it was cool to publish. You're right that this is a fragile situation. Maybe we should recommend that if you firewall your ORPort, you also set "AssumeReachable 1" in your torrc? --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Why is my bridge not publishing statistics?
I searched for the Snowflake bridge in Atlas, and couldn't find it. Its fingerprint is 2B280B23E1107BB62ABFC40DDCC8824814F80A72. Its torrc is stock "Last updated 9 October 2013 for Tor 0.2.5.2-alpha" except for these settings: ContactInfo David Fifield SOCKSPort 0 ORPort 9001 BridgeRelay 1 ExtORPort auto ServerTransportPlugin snowflake exec /usr/local/bin/snowflake-server --acme-hostnames snowflake.bamsoftware.com --acme-email d...@torproject.org --log /var/log/tor/snowflake-server.log ServerTransportListenAddr snowflake 0.0.0.0:443 Its ORPort 9001 is blocked by the local firewall, because it is meant to be only a Snowflake bridge, and not a vanilla bridge. (Most of the default Tor Browser obfs4 bridges are configured the same way, with their ORPort blocked.) There are these messages in the log (which I exxpected): [warn] Your server (37.218.242.151:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Why is the bridge not appearing in Atlas? I initially suspected https://bugs.torproject.org/18050, whose changelog entry is: - Check that both the ORPort and DirPort (if present) are reachable before publishing a relay descriptor. Otherwise, relays publish a descriptor with DirPort 0 when the DirPort reachability test takes longer than the ORPort reachability test. Closes bug #18050. Reported by "starlight", patch by "teor". Bugfix on 0.1.0.1-rc, commit a1f1fa6ab on 27 Feb 2005. But if it's the case that an unreachable ORPort causes descriptors not to be uploaded, then why do the default obfs4 bridges appear in Atlas? For example: https://atlas.torproject.org/#details/D9C805C955CB124D188C0D44F271E9BE57DE2109 https://atlas.torproject.org/#details/D3D4A456FCB5F301F092F6A49ED671B84B432FB8 https://atlas.torproject.org/#details/11A3982C417AF37230F576006405BE5338F41C09 Actually, now that I look at it, I notice some other default bridges are not present in Atlas, for example the two from https://bugs.torproject.org/21917, which went out in Tor Browser 6.5.2: C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4 0BAC39417268B96B9F514E7F63FA6FBA1A788955 What's going on and how can we fix it? You can find a list of default bridge fingerprints here: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/PTConfigs/bridge_prefs.js ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
