Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  closed
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:  fixed
 Keywords:  reachability   |  Actual Points:  2
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by phw):

 * status:  needs_review => closed
 * resolution:   => fixed
 * actualpoints:   => 2


Comment:

 I'm closing this because our short-term solution is now in place. Here's a
 summary:

 * The service is now deployed at https://bridges.torproject.org/scan/.
 * The code is available at https://github.com/NullHypothesis/obfs4PortScan
 (and, once #30715 is done, on our gitweb).
 * We're using polyanthum's Apache reverse proxy as front for the service
 (see #30703), so we only need to listen on localhost.
 * The service runs as user `bridgescan` (see #30714) and we're using a
 [https://help.torproject.org/tsa/doc/services/ local systemd script] to
 have it start at boot.
 *
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam/InfrastructureMonitoring
 Our sysmon deployment] is monitoring the service.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by anarcat):

 i've document how to start services with systemd in
 https://help.torproject.org/tsa/doc/services/

 i prefer this to cron as it allows much more flexibility and i can restart
 services when there are security upgrades.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by arma):

 Replying to [comment:10 phw]:
 > We should also make the service start automatically at boot -- perhaps
 by creating a systemd script?

 If it's just run as a normal user, and doesn't need to be root or
 anything, you can start it on boot with a line in that user's crontab,
 like
 {{{
 @reboot (cd /home/tord/run; ../git/src/app/tor -f moria1-orrc)
 }}}

 That's much lighter-weight than a systemd script, and avoids having
 anything run as higher privileges.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by phw):

 On IRC, we concluded that we should add another `ProxyPass` directive to
 our apache config on polyanthum, so bridge operators can access this
 service over a URL such as bridges.torproject.org/scan/.

 We should also make the service start automatically at boot -- perhaps by
 creating a systemd script?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by phw):

 Replying to [comment:8 cohosh]:
 > I think the `timeout` input to
 [https://github.com/NullHypothesis/obfs4PortScan/blob/fix/30472/handlers.go#L70
 isTCPPortReachable] is redudant now.
 [[br]]
 Yes, good catch.
 [[br]]
 > As long as you're not logging IP addresses, this seems fine to me.
 You're also not exporting the data, it's mostly a consideration in the
 case that the machine or service is compromised. I don't see issues with
 an attacker getting ahold of the number of requests made and the times at
 which they are made. There are probably easier ways to find out whatever
 information they would hope to find out from these logs anyway.
 [[br]]
 Yes, agreed.

 Ok, I'll move forward with setting up the service on polyanthum. Thanks
 for the reviews!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by cohosh):

 Replying to [comment:7 phw]:
 > Replying to [comment:6 cohosh]:
 > > - A nicer way to express the timeout
 [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43
 here] would be
 > >  {{{ timeout := 3* time.Second }}}, but even better would be to set a
 commented constant at the beginning of the file.
 > [[br]]
 > Good point, fixed in the following branch:
 https://github.com/NullHypothesis/obfs4PortScan/tree/fix/30472
 I think the `timeout` input to
 [https://github.com/NullHypothesis/obfs4PortScan/blob/fix/30472/handlers.go#L70
 isTCPPortReachable] is redudant now.
 > [[br]]
 > > - Do you also want timestamps in your logs?
 > [[br]]
 > I would like to keep timestamps because they tell us how much (ab)use
 the service is seeing. Do you see any issues with timestamps?
 >
 As long as you're not logging IP addresses, this seems fine to me. You're
 also not exporting the data, it's mostly a consideration in the case that
 the machine or service is compromised. I don't see issues with an attacker
 getting ahold of the number of requests made and the times at which they
 are made. There are probably easier ways to find out whatever information
 they would hope to find out from these logs anyway.
 > On a related note: I noticed that the http package can log error
 messages that include the client's IP address. I included snowflake's safe
 logger to prevent this from happening.
 > [[br]]
 Oh good point, I'm glad the package is useful here.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by phw):

 Replying to [comment:6 cohosh]:
 > - A nicer way to express the timeout
 [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43
 here] would be
 >  {{{ timeout := 3* time.Second }}}, but even better would be to set a
 commented constant at the beginning of the file.
 [[br]]
 Good point, fixed in the following branch:
 https://github.com/NullHypothesis/obfs4PortScan/tree/fix/30472
 [[br]]
 > - In `main()` you could have the certificate and key files passed in as
 specific arguments such as `--cert` or `--key` as the broker does
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/broker/broker.go#n263 here]. The advantage
 of this is making sure they are passed in the correct order (which should
 be documented outside of the usage function).
 [[br]]
 Also fixed in the same branch.
 [[br]]
 > - Do you also want timestamps in your logs?
 [[br]]
 I would like to keep timestamps because they tell us how much (ab)use the
 service is seeing. Do you see any issues with timestamps?

 On a related note: I noticed that the http package can log error messages
 that include the client's IP address. I included snowflake's safe logger
 to prevent this from happening.
 [[br]]
 > As a more general note, is this meant to be used in an automated way for
 bridge operators to log and report to themselves when their port isn't
 reachable? Or as an occasional manual check? I know this is something
 temporary so maybe not a large consideration, but returning something
 other than a `200 OK` if the port is unreachable would make it easier to
 write a client-side go program that performs this check automatically.
 [[br]]
 At this point it's meant for occasional manual checks. I plan to add a
 link to the service to our
 
[https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy
 obfs4proxy installation guide]. I originally intended this service to be
 used as an API (see the bottom paragraph of the ticket's description) but
 it's not clear if we want yet another service that deals with bridge data.
 The better way forward may be to improve BridgeDB.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by cohosh):

 Replying to [comment:4 phw]:
 > I built a small golang service that lets bridge operators test their
 obfs4 port. For now, the code is available at
 https://github.com/NullHypothesis/obfs4PortScan.
 >
 > I set up a demo at https://nymity.ch:8081. After entering your bridge's
 IP address and port, the service tells you if the port is reachable or
 not.  If the port is unreachable, the service tells you the error message
 it got. The tool also has a simple rate limiter that limits requests to an
 average of one per second, with bursts of up to five per second.
 >
 Awesome! It worked for me :)

 I just have a few minor comments:
 - A nicer way to express the timeout
 [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43
 here] would be
  {{{ timeout := 3* time.Second }}}, but even better would be to set a
 commented constant at the beginning of the file.
 - In `main()` you could have the certificate and key files passed in as
 specific arguments such as `--cert` or `--key` as the broker does
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/broker/broker.go#n263 here]. The advantage
 of this is making sure they are passed in the correct order (which should
 be documented outside of the usage function).
 - Do you also want timestamps in your logs?

 As a more general note, is this meant to be used in an automated way for
 bridge operators to log and report to themselves when their port isn't
 reachable? Or as an occasional manual check? I know this is something
 temporary so maybe not a large consideration, but returning something
 other than a `200 OK` if the port is unreachable would make it easier to
 write a client-side go program that performs this check automatically.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by gaba):

 * sponsor:   => Sponsor19


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+---
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:
   |  needs_review
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by phw):

 * status:  assigned => needs_review


Comment:

 I built a small golang service that lets bridge operators test their obfs4
 port. For now, the code is available at
 https://github.com/NullHypothesis/obfs4PortScan.

 I set up a demo at https://nymity.ch:8081. After entering your bridge's IP
 address and port, the service tells you if the port is reachable or not.
 If the port is unreachable, the service tells you the error message it
 got. The tool also has a simple rate limiter that limits requests to an
 average of one per second, with bursts of up to five per second.

 What can we improve?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Yes, good summary.

 I was wary at first of a little web app to help with testing, because it's
 yet another place to go break into or watch; but I think so long as we
 know it is a short term fix until the proper reachability testing gets
 into the version of Tor that people have, the usability boost makes it an
 acceptable risk.

 I expect we have quite a few obfs4 bridges right now that are firewalled
 off -- and if we do a campaign to get more people to run obfs4 bridges,
 without a good easy intuitive step for "then check if it works" we'll have
 even more.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by phw):

 We had a short discussion on IRC and concluded the following:
 * We don't want another central service that collects all the data.
 * A bridge can self-test by having its tor client establish a TCP
 connection with its obfs4 port (see #30477). Tor can then warn the
 operator in its log file if the test fails. Unfortunately, this won't help
 if we ever deploy a PT that speaks UDP.
 * Some operators will ignore their log files, though, so we will still be
 collecting unreachable obfs4 bridges. BridgeDB should therefore learn how
 to test all of its bridges by speaking their respective transport
 protocol. It should not hand out bridges that are unreachable or otherwise
 broken.

 We were left wondering what obfs4 operators should do in the short term,
 before #30477 is done, to figure out if their bridge is reachable. One way
 forward would be a simple web page, hosted by us, that asks for an IP
 address, and a port as input. The service then tries to establish a TCP
 connection to the given tuple, and lets the user know if it succeeded or
 failed. The service doesn't need to log or remember anything, and we can
 run it on polyanthum, the host that also runs BridgeDB.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing (was: Implement a mechanism for PT rechability testing)

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
---+--
 Reporter:  phw|  Owner:  phw
 Type:  project| Status:  assigned
 Priority:  High   |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Major  | Resolution:
 Keywords:  reachability   |  Actual Points:
Parent ID:  #30471 | Points:
 Reviewer: |Sponsor:
---+--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs