On Fri, Nov 11, 2022 at 09:45:32PM +0100, binarynoise wrote: > Went to settings, checked the bridge settings: yes, I had entered by > bridge-line. Odd. > > Continued to the tor logs: oh, bridge-line didn't parse. Interesting. > (I put in the server's identity key ed25519 fingerprint instead of the > not-ed25519 one and put my bridges name somewhere there too). > > Ok, but why doesn't it tell me? > Why is there no big "Couldn't connect to your configured bridges"- > warning after hitting the connect-to-tor-button?
This is a Tor Browser bug: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40551 and yes it is a big deal because users expect that once they've entered a bridge address, and Tor Browser didn't complain, then they will be successfully using it. This bug bit us recently because the new default Snowflake bridge line was too long, causing Tor to log and not use it, so when you selected "I want a built-in bridge, how about Snowflake" you thought you were using snowflake when actually you weren't: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40665 One small question though: you say above that "checked the bridge settings: yes, I had entered by bridge-line" -- but I believe that one of the symptoms of the bug is that the bridge line silently vanishes, i.e. you set it but then it never gets set and the settings page says you're not using bridges. So please go back and check if you really had the behavior you describe, since it would be a new and not-yet-known issue. > Anyway, does some tool exist, where you enter your bridge's information > or run it on the server, that tells you if the recommended versions of > tor + dependencies are installed and actually used? > That would make the task of keeping the bridge healthy easier. We have some tools here, but I agree that we could do more on the usability side: (1) The bridgestrap tool tells you whether our remote server was able to handshake with your obfs4 bridge. Your obfs4 bridge should log a personalized bridgestrap url on successful startup: Nov 12 13:59:54.694 [notice] You can check the status of your bridge relay at https://bridges.torproject.org/status?id=3E2CEE334E23FC346FF4E5797F906B9A1C18EFC4 See https://bugs.torproject.org/tpo/core/tor/30477 for more history. (2) The relay-search page for your bridge has a bunch of info about it: https://metrics.torproject.org/rs.html#details/3E2CEE334E23FC346FF4E5797F906B9A1C18EFC4 and relay-search ought to, but I think does not yet, fetch the bridge status entry and display it too. (3) dcf wrote a script to remotely assess whether your obfs4 bridge is running an old obfs4 version or a new enough obfs4 version. It is currently a confidential ticket, because it includes details about the distinguisher that a censor might use to gain a small advantage. But least I checked it is scheduled to go public on Nov 15 i.e. in a few days. When it does, you'll be able to read it and find the script at https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/91 In summary: we have some good building blocks here, but the 'last mile' of relay operator usability definitely needs some work. The bridgestrap tool should probably integrate dcf's testing script, so it learns and reports not just "can I handshake with the obfs4 port" but also "is it running the old buggy version or not". And then relay-search should import that info and display it too. I think there are not enough anti-censorship devs, and many many anti-censorship tools, so this might be good timing for the community to step in and help. Thanks! --Roger _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
