date:20200309

[tor-bugs] #33583 [Core Tor/Chutney]: Stop setting AssumeReachable on chutney relays and bridges

2020-03-09 Thread Tor Bug Tracker & Wiki

#33583: Stop setting AssumeReachable on chutney relays and bridges
--+---
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  ipv6, prop311
Actual Points:|  Parent ID:  #33232
   Points:  0.5   |   Reviewer:
  Sponsor:  Sponsor55-must|
--+---
 We need to stop setting AssumeReachable on relays and bridges in chutney
 networks, so they do reachability self-tests.

 We should continue to set AssumeReachable on authorities (including the
 bridge authority), because it disables authority to relay reachability
 tests. (These tests are still performed on a half-hourly schedule, even in
 chutney networks. And they are out of scope for Sponsor 55.)

 After we implement this change, we should also be able to implement
 #33581.

--
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] #33379 [Core Tor/Chutney]: Make chutney wait for all relays in the consensus before verifying

2020-03-09 Thread Tor Bug Tracker & Wiki

#33379: Make chutney wait for all relays in the consensus before verifying
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:  2
Parent ID:  #33232| Points:  0.5
 Reviewer:  ahf   |Sponsor:  Sponsor55-must
--+
Changes (by teor):

 * status:  needs_revision => needs_review
 * reviewer:  nickm => ahf
 * actualpoints:  0.5 => 2


Comment:

 I spoke with Alex today, and he's happy to review these chutney changes.

 Here's my draft PR:
 * chutney: https://github.com/torproject/chutney/pull/57

 It passes tor's `make test-network-all` locally, but chutney's CI is still
 running. There might be some issues with 0.3.5, like there were in #33378.

--
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] #33378 [Core Tor/Chutney]: Require chutney node bootstrap before running verify

2020-03-09 Thread Tor Bug Tracker & Wiki

#33378: Require chutney node bootstrap before running verify
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  ipv6, prop311 |  Actual Points:  0.5
Parent ID:  #33050| Points:  0.5
 Reviewer:  ahf   |Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => closed
 * resolution:   => fixed
 * parent:  #33232 => #33050


Comment:

 Let's do the review and merge for this ticket in #33050.

--
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] #33582 [Core Tor/Tor]: Make bridges wait until they have bootstrapped, before publishing their descriptor

2020-03-09 Thread Tor Bug Tracker & Wiki

#33582: Make bridges wait until they have bootstrapped, before publishing their
descriptor
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, tor-relay, prop311,  |  Actual Points:
  outreachy-ipv6 |
Parent ID:  #33232   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor55-can
-+-

Comment (by arma):

 Yes please, this sounds like a fine plan.

 To clarify, right now both bridges and relays *do* wait until they have
 reached 100% bootstrapped, if AssumeReachable is default (0)? But this bug
 appears when AssumeReachable is set to 1, and then it tries to publish
 without regard for whether it has bootstrapped to 100%?

--
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] #33330 [Circumvention/Snowflake]: Use Go modules for Snowflake

2020-03-09 Thread Tor Bug Tracker & Wiki

#0: Use Go modules for Snowflake
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:  .2
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+

Comment (by dcf):

 Replying to [comment:6 cohosh]:
 > Yeah this is weird. I'm still not sure why dependencies are sometimes
 added with `// indirect`. As far as I can tell, they are mostly not
 necessary to get a working build.
 [https://github.com/golang/go/wiki/Modules#why-does-go-mod-tidy-record-
 indirect-and-test-dependencies-in-my-gomod This resource] suggests that
 they are required by dependencies that don't have module support, but I
 suspect there's a bug in how they determine that.

 I think I see now. github.com/golang/protobuf and golang.org/x/text are
 only used by tests, and they are not packages themselves, but modules
 containing packages. The actual packages are
 github.com/golang/protobuf/proto and golang.org/x/text/secure/bidirule.
 `go mod why -m` searches for subpackages of that form.
 {{{
 $ go mod why github.com/golang/protobuf
 # github.com/golang/protobuf
 (main module does not need package github.com/golang/protobuf)

 $ go mod why golang.org/x/text
 # golang.org/x/text
 (main module does not need package golang.org/x/text)

 $ go mod why -m github.com/golang/protobuf
 # github.com/golang/protobuf
 git.torproject.org/pluggable-transports/snowflake.git/client
 github.com/pion/webrtc/v2
 github.com/pion/quic
 github.com/lucas-clemente/quic-go
 github.com/lucas-clemente/quic-go.test
 github.com/onsi/ginkgo
 github.com/onsi/ginkgo/internal/remote
 github.com/onsi/ginkgo/internal/spec_iterator
 github.com/onsi/ginkgo/internal/spec_iterator.test
 github.com/onsi/gomega/ghttp
 github.com/golang/protobuf/proto

 $ go mod why -m golang.org/x/text
 # golang.org/x/text
 git.torproject.org/pluggable-transports/snowflake.git/broker
 golang.org/x/crypto/acme/autocert
 golang.org/x/net/idna
 golang.org/x/text/secure/bidirule
 }}}

--
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] #33577 [Applications/Tor Browser]: Picture-in-Picture not working with dom.w3c_pointer_events.enabled=false

2020-03-09 Thread Tor Bug Tracker & Wiki

#33577: Picture-in-Picture not working with dom.w3c_pointer_events.enabled=false
--+--
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > We should think about switching to Mozilla's defense and enabling
 pointer events again where they are enabled by a default Firefox.

--
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] #33010 [Metrics/Ideas]: Monitor cloudflare captcha rate: do a periodic onionperf-like query to a cloudflare-hosted static site

2020-03-09 Thread Tor Bug Tracker & Wiki

#33010: Monitor cloudflare captcha rate: do a periodic onionperf-like query to a
cloudflare-hosted static site
---+--
 Reporter:  arma   |  Owner:  metrics-team
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health gsoc-ideas  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by woswos):

 I wanted to conduct a few simple experiments on this issue. I will start
 by explaining my setup and continue with the experiments themselves.

 '''Domain Setup'''
 I registered two domains ([https://captcha.wtf/ captcha.wtf] and
 [https://exit11.online/ exit11.online]) with IPv4 records on Cloudflare.
 After playing with Cloudflare settings, I understood that domain owners
 have an important role in the way Cloudflare blocks Tor users.

 A new free Cloudflare account comes with a default security level (like
 the security levels in the Tor browser and as comment:5 mentioned), and
 the default security level doesn't explicitly block Tor users. I am not
 saying Cloudflare is innocent, but they don't mention a possible Tor user
 blocking at this security level. However, Tor shows up as a country on the
 Cloudflare firewall settings, and it is possible to block Tor users based
 on this firewall rule. I think they have a list of Tor exit node IPs, and
 they use this list to perform the filtering. They "offer" JS and Captcha
 challenges in addition to simple blocking, as shown in the image below:

 [[Image(https://bottomless-pit.barkin.io/tor-firewall-rules.png,
 width=100%)]]

 I think that's why some Tor users face more captcha challenges at higher
 Tor browser security levels. JavaScipt is blocked at higher security
 levels, and they can't pass the Cloudflare JS challenges.
 \\
 Also, if a firewall rule related to Tor is set, Cloudflare applies that
 rule (for example, the never-ending captcha challenge) all the time even
 if the user has somehow managed to pass the challenge 5 seconds ago - I
 think that is the part all of us hate, it just creates an endless loop. A
 sample Cloudflare firewall record below shows that the same IP address is
 continuously challenged over and over again, even after successfully
 passing the captcha challenge.

 [[Image(https://bottomless-pit.barkin.io/tor-firewall-1.png, width=100%)]]
 \\
 exit11.online has the default Cloudflare configuration without any
 additional firewall or protection. I am guessing that this would be the
 case with most of the average Cloudflare users. I also registered the
 [https://bypass.exit11.online/ bypass.exit11.online] subdomain, which
 bypasses the Cloudflare proxy and only utilizes Cloudflare as a DNS
 hosting service and CDN.

 [[Image(https://bottomless-pit.barkin.io/tor-cloudflare-exit11.png,
 width=100%)]]
 \\
 captcha.wtf has the default Cloudflare configuration ''with the additional
 firewall configuration'' for blocking Tor users, as I have mentioned
 previously. I registered this second domain to see the difference between
 using the default Cloudflare settings and adding additional firewall
 rules. I also registered the [https://bypass.captcha.wtf/
 bypass.captcha.wtf] subdomain, which bypasses the Cloudflare proxy and
 only utilizes Cloudflare as a DNS hosting service and CDN.

 [[Image(https://bottomless-pit.barkin.io/tor-cloudflare-wtf.png,
 width=100%)]]

 [[Image(https://bottomless-pit.barkin.io/tor-cloudflare-wtf-firewall.png,
 width=100%)]]
 \\
 Both of these domains have a very simple static "Hello world!" page at
 `/index.html`, and there is a more complicated page at `/complex.html`
 that loads resources from different locations. Additionally, captcha.wtf &
 exit11.online have SSL certificates issued by Cloudflare and
 bypass.captcha.wtf & bypass.exit11.online have SSL certificates issued by
 Let's Encrypt. I thought that these might have an effect on the way
 Cloudflare behaves.

 '''Experimenting'''
 Later, I used the Python script mentioned in comment:7 (it uses httplib)
 and the tor-browser-selenium mentioned in comment:13 to conduct a few
 simple experiments. I wrote another script to fetch different domain
 combinations via tor-browser-selenium and Python's httplib. For example,
 fetching bypass.exit11.online, exit11.online, exit11.online/complex.html,
 and bypass.exit11.online/complex.html via both tor-browser-selenium and
 Python's httplib.

 '''Results'''
 After fetching each combination about 100 times at one minute intervals,
 the domain with the default configuration (exit11.online) was not blocked
 a single time via both Tor and httplib. However, the domain with
 additional f

[tor-bugs] #33582 [Core Tor/Tor]: Make bridges wait until they have bootstrapped, before publishing their descriptor

2020-03-09 Thread Tor Bug Tracker & Wiki

#33582: Make bridges wait until they have bootstrapped, before publishing their
descriptor
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-bridge, tor-relay, prop311,
 Severity:  Normal   |  outreachy-ipv6
Actual Points:   |  Parent ID:  #33232
   Points:  1|   Reviewer:
  Sponsor:   |
  Sponsor55-can  |
-+-
 When `AssumeReachable` is set on bridges, there's a race condition when
 bridges try to publish their descriptor to the bridge authority:
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Bridges will eventually try to publish their descriptors again, when they
 become dirty.

 We should make bridges wait until they have bootstrapped, before they try
 to publish their descriptors. (This might be a good change for relays as
 well: there isn't much point in publishing a relay that can't bootstrap.)

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

[tor-bugs] #33581 [Core Tor/Chutney]: Restore bridge networkstatus checks in chutney

2020-03-09 Thread Tor Bug Tracker & Wiki

#33581: Restore bridge networkstatus checks in chutney
--+---
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  ipv6, prop311
Actual Points:|  Parent ID:  #33232
   Points:  0.1   |   Reviewer:
  Sponsor:  Sponsor55-must|
--+---
 In chutney networks, there's a race condition when bridges try to publish
 their descriptor to the bridge authority:
 * bridges have AssumeReachable set
 * bridges try to publish their descriptors before bootstrapping
 * but bridges can't publish their descriptors, because they don't have
 enough directory info to build a circuit to the bridge authority

 Also, bridges do not retry publishing their descriptor immediately after
 they bootstrap.

 Once we make bridges do reachability checks in chutney, they will wait to
 bootstrap, do reachability checks, then try to publish their descriptors.

 So we can enable the bridge networkstatus checks again.

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

[tor-bugs] #33580 [Applications]: Allow WebAssembly in extensions

2020-03-09 Thread Tor Bug Tracker & Wiki

#33580: Allow WebAssembly in extensions
-+--
 Reporter:  pipboy96 |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Applications
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 WebAssembly [https://github.com/EFForg/https-everywhere-lib-wasm is used
 by HTTPS Everywhere] to speed up applicable ruleset lookup. To my best
 knowledge allowing WebAssembly for extensions only while keeping it
 disabled for web content will not reduce browser security in any way.

--
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] #33379 [Core Tor/Chutney]: Make chutney wait for all relays in the consensus before verifying

2020-03-09 Thread Tor Bug Tracker & Wiki

#33379: Make chutney wait for all relays in the consensus before verifying
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:  0.5
Parent ID:  #33232| Points:  0.5
 Reviewer:  nickm |Sponsor:  Sponsor55-must
--+

Comment (by teor):

 Here is my work-in-progress branch, it works for about half the current
 chutney networks:
 * do not merge: https://github.com/torproject/chutney/pull/57

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

[tor-bugs] #33579 [Webpages/Website]: Please remove/deactivate job posting from website (Executive Assistant)

2020-03-09 Thread Tor Bug Tracker & Wiki

#33579: Please remove/deactivate job posting from website (Executive Assistant)
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please remove/deactivate the Executive Assistant job posting on our jobs
 page. We are in the final stages of interviewing and will be
 making/announcing a decision soon.
 Thanks.


 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAl5mziMACgkQugyUAPgP
 kc5FVw//brH19en9sb5ler5Pa0xcu4U4cpiRIpVyl1Nmx0gh5XqVriOcTdK8Do3D
 oHH8c1tCpTEp83x0zQ5YGFuSvJlja5nD9veLY7aMd/+Kephcq7tqoqEAiDCgQ8xB
 vE2pMDQjFqDIZKQsL/o+SIWWMN2WaQEyLOMFv0qiaN2sYtAXEYIpULSNr6BHyIhu
 aeRmUe4iPgXXGPYXMl48x97BoylNkyBD5c/0SVUJunsQHpB1p0g5qMGjTn3aa8r7
 bjJZMThSIiYzsgp/AZLhi7+43RvcAVCnUvimdCol89i/oZPXRxCGskv+IEJHUy+9
 m144dYhRRbTzj2wAV5gxb8lkktKEjpSMK6vUgxST/1ScVSPQIsrzzO8K/H7oqoSU
 QZWhRWWe2Ci16fx1MI3WibmAIFc3R+Dc4DBu3TNhXtsBPnJGXldvq32FEGI4oK8L
 QvO0lqUYn9QXRZj5IEmPKQFkuhP2OXgtLhvspZGu/rjAzSjy6vmZfmR7ArQKpN2t
 qEyHx7w6rqcdQYN8s3U4JlxOtH0OcByr1sOG8M2Ziemr8aJ60FFM4UliraT76bls
 7POJLxLIK5P9n09XN+wyRjDyFqY/ykqR90PnvLIqzKZSx1pUvTEGHgy4BsrlzP8z
 ohImTZv/uQWW7TRXhC2ho9RaYzxe2RxfmhiEEwj9AkJ8lBMFOq4=
 =93hE
 -END PGP SIGNATURE-
 }}}

--
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] #33330 [Circumvention/Snowflake]: Use Go modules for Snowflake

2020-03-09 Thread Tor Bug Tracker & Wiki

Comment (by cohosh):

Merged at [https://gitweb.torproject.org/pluggable-
transports/snowflake.git/commit/?id=58b52eb9f7987789d8e90a982a6df16013e200dd
6013e200dd].

Yeah this is weird. I'm still not sure why dependencies are sometimes
added with `// indirect`. As far as I can tell, they are mostly not
necessary to get a working build.
[https://github.com/golang/go/wiki/Modules#why-does-go-mod-tidy-record-
indirect-and-test-dependencies-in-my-gomod This resource] suggests that
they are required by dependencies that don't have module support, but I
suspect there's a bug in how they determine that.

Anyways, I opened #33578 to bump the version of Snowflake in Tor Browser.
This is a bit overdue as there have been several improvements since the
last update. It also includes the changes necessary since merging this
branch.

This required a few more hacks than the obfs4 project to account for the
use of v2 modules by pion-webrtc (see [https://gitweb.torproject.org
/pluggable-

transports/snowflake.git/tree/client/lib/webrtc.go?id=58b52eb9f7987789d8e90a982a6df16013e200dd#n12
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

1 2 >

1 - 100 of 175 matches

Mail list logo