[tor-relays] Difficulties testing my bridge

Hello everyone,

I run a bridge and as I was doing maintenance on my server, I wanted to
check whether my bridge works and whether the bandwidth is really as
low as advertised in the relay search (it's not, maybe because no-one
uses it, as it's on reserved distribution).

So I started my tor-browser, opened htop locally and on the server and
started browsing.
Everything went smoothly, but something was odd: I did not see any
traffic on my server (that idles most of the time, so I should see my
bridges traffic).

Checked connection-info: no bridge there.

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?

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.

Greetings
binarynoise

···

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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:

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:

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 Tor should self-test reachability of TCP listeners exposed by PT's (#30477) · Issues · The Tor Project / Core / Tor · GitLab 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

···

On Fri, Nov 11, 2022 at 09:45:32PM +0100, binarynoise wrote:

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

> 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:
Don't silently log and continue when changing tor's config fails (#40551) · Issues · The Tor Project / Applications / Tor Browser · GitLab
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.

That looks like what I experienced. I always had to look into the logs
to see if it succeeded now.

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.

Yes it did vanish sometimes like this:

In the block allowing me to share my bridge via qr-code, it showed me
some bridge line. It didn't vanish but it didn't always reflect the
line I entered into "add bridge manually".

In the input field, the bridge line would vanish sometimes, I didn't
pay much attention to when, but I think it had to do with my
experiments until I had correctly assembled the bridge-line for my
bridge. I tested too many things, I won't be able to reproduce.

But the initial bridge-line I set some time ago with the wrong
fingerprint and the name in it was saved and shown in the input field,
so it doesn't always vanish if invalid input is provided.

> 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:

You could maybe link (1) and (3) additionally to (2) in the post-
install instructions:

(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

I eventually found it, but it does only show you *that* it's a obfs4
bridge, not which version it's using.

(2) The relay-search page for your bridge has a bunch of info about it:
Relay Search
and relay-search ought to, but I think does not yet, fetch the bridge
status entry and display it too.

It does not yet and it only shows the Tor version. (Would it show a
warning, when it's outdated?)

(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

If I don't forget, I'll try it.

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.

I'll see if I can contribute something myself, but I fear I'm not
experienced enough yet for that. Maybe I can at least fill some gaps in
the documentation.
For now I can only contribute my bridge on my server and the snowflakes
at home.

Thanks for your reply
binarynoise

···

Am Samstag, dem 12.11.2022 um 14:02 -0500 schrieb Roger Dingledine:

On Fri, Nov 11, 2022 at 09:45:32PM +0100, binarynoise wrote:

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

The issue is still not accessible publicly, GitLab returns 404, even
though it's two weeks later.

Greetings
binarynoise

···

Am Samstag, dem 12.11.2022 um 14:02 -0500 schrieb Roger Dingledine:

(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

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Quoting binarynoise (2022-12-02 17:18:35)

···

Am Samstag, dem 12.11.2022 um 14:02 -0500 schrieb Roger Dingledine:
> (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

The issue is still not accessible publicly, GitLab returns 404, even
though it's two weeks later.

We are trying to get at least half of the bridges updated before we make it
public:

I'm sorry for the long wait.

If you are reading this and run a bridge, please check that you are running
obfs4proxy version 0.0.14 and tor has being restarted since it got upgraded :slight_smile:

--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.