Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Replying to [comment:17 arthuredelstein]:
 > Maybe CloudFlare could be persuaded to use CAPTCHAs more precisely?
 >
 > That is, present a CAPTCHA only when:
 > 1. the server owner has specifically requested that CAPTCHAs be used
 > 2. the server is actively under DoS attack, and
 > 3. the client's IP address is currently a source of the DoS.

 That seems interesting - I wish we had data to understand if these choices
 would help - it seems opaque how "threat scores" for IP addresses are
 computed. Is there any public information about it?

 >
 > I think it's hugely overkill to show CAPTCHAs all the time to all Tor
 users for every CloudFlare site. It's also unreasonable to maintain a
 "reputation" for a Tor exit node.

 I agree.

 > On top of this, Google's reCAPTCHA is buggy and frequently impossible to
 solve. Has CloudFlare considered other CAPTCHAs, or discussed reCAPTCHA's
 problems with Google?

 I'm also interested in understanding the dataflow - could the FBI go to
 Google to get data on all CloudFlare users? Does CF protect it? If so -
 who protects users 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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by arthuredelstein):

 Maybe CloudFlare could be persuaded to use CAPTCHAs more precisely?

 That is, present a CAPTCHA only when:
 1. the server owner has specifically requested that CAPTCHAs be used
 2. the server is actively under DoS attack, and
 3. the client's IP address is currently a source of the DoS.

 I think it's hugely overkill to show CAPTCHAs all the time to all Tor
 users for every CloudFlare site. It's also unreasonable to maintain a
 "reputation" for a Tor exit node.

 On top of this, Google's reCAPTCHA is buggy and frequently impossible to
 solve. Has CloudFlare considered other CAPTCHAs, or discussed reCAPTCHA's
 problems with Google?

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Replying to [comment:10 marek]:
 > @ioerror: you are doing this again. You are mixing your opinions with
 technical reality. Please stop insulting me. Please focus on what can we
 can technically do to fix the problem.

 I'm unclear on what I've said or done that is insulting you? Could you
 clarify? It certainly isn't my attempt or intent to insult you.

 What is my opinion and what is technical reality? Could you enumerate that
 a bit? I've asked many questions and it is important that we discuss the
 wide range of topics here.

 >
 > > Here is a non-cryptographic, non-cookie based solution: Never prompt
 for a CAPTCHA on GET requests.
 >
 > There are a number of problems with this model.
 >

 There are a number of problems with the current model - to be clear - and
 so while there are downsides to the read-only GET suggestion, I think it
 would reduce nearly all complaints by end users.

 >
 > (POST is hard) First, what actually the proxy should *do* on the POST?
 Abort your POST, serve captcha, and ask you to fill the POST again? Or
 accept your 10meg upload, serve captcha and ask you to upload it again?
 Now think about proxy behaviour during an attack. Doing captcha validation
 on POST is not a trivial thing.
 >

 Off the top of my head - to ensure I reply to everything you've written:

 It seems reasonable in many cases to redirect them on pages where this is
 a relevant concern? POST fails, failure page asks for a captcha solution,
 etc.

 >
 > (blocking regions) Second, during an "attack" (call it ddos or
 something) the website owners often decide to block traffic from ceirtain
 regions. Many businesses care only about visitors from some geographical
 region, and in case of a DDoS are happy to just DROP traffic from other
 regions. This is not something to like or dislike. This is a reality for
 many website owners. Serving captcha is strictly better than disallowing
 the traffic unconditionally.

 Actually, a censorship page with specific information ala HTTP 451 would
 be a nearly in spec answer to this problem. Why not use that? You're
 performing geographic discrimination on behalf of your users - this
 censorship should be transparent. It should be clear that the site owner
 has decided to do this - and there is less of a need to solve a captcha by
 default.

 Though in the case of Tor - you can't do this properly - which is a reason
 to specifically treat Tor users as special. Visitors may be in the region
 and Tor is properly hiding them. That is a point in the direction of
 having an interstitial page that allows a user to solve a captcha.

 >
 > (Not only spam, load as well) Third, there regularly are bot "attacks"
 that just spam website with continous flood of GET requests, for example
 to check if the offered product is released, the promotion started or
 price updated. This is a problem for some website owners and they wish to
 allow only traffic from vetted sessions.
 >

 Why not just serve them an older cached copy?

 > The underlying problem, is that for any ddos / spam protection system
 the source IP address is a very strong signal. Unfortunately many Tor exit
 IP's have bad IP reputation, because they _ARE_ often used for unwanted
 activity.

 Do you have any open data on this?

 > @willscott:
 >
 > > What sort of data would qualify as an 'i'm a human' bit?
 >
 > Let's start with something not-worse than now: a captcha solved in last
  minutes.
 >

 This feels circular - one of the big problems is that users are unable to
 solve them after a dozen tries. We would not have as many complaining
 users if we could get this far, I think.

 > > This sounds very much like something that could be provided through
 the use of zero-knowledge proofs
 >
 > Yup. What do we do to implement one both on ddos protection side and on
 TBB side?

 My first order proposition would be to solve a cached copy of the site in
 "read only" mode with no changes on the TBB side. We can get this from
 other third parties if CF doesn't want to serve it directly - that was
 part of my initial suggestion. Why not just serve that data directly?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online

Re: [tor-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by wwaites):

 To quantify the scope of the problem slightly, a few weeks ago I measured
 that 10% of the Alexa top 25k are behind Cloudflare.

 It would be helpful if we had a nice, well written, easy to understand
 explanation of the problem that we could give to site owners. Of those
 that I have contacted, some get it and adjust things quickly, but some
 struggle to understand what the problem is.

--
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] #18358 [Tor]: Tor Browser is tracking user activity by sending .onion names.

[Tor Bug Tracker & Wiki]

#18358: Tor Browser is tracking user activity by sending .onion names.
--+-
 Reporter:  ikurua22  |  Owner:
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor   |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+-

Comment (by arma):

 More details? Where exactly should I look at torrc?

 (I think you are mistaken.)

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 {{{
 CloudFlare is in a position to inject JavaScript into sites
 }}}

 This alone should be reason enough for the security warning. People might
 be viewing sites which they believe to be in a different jurisdiction and
 suddenly giving control to a US entity.

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:10 marek]:
 >
 > > Here is a non-cryptographic, non-cookie based solution: Never prompt
 for a CAPTCHA on GET requests.
 >
 > There are a number of problems with this model.
 >
 > (POST is hard) First, what actually the proxy should *do* on the POST?
 Abort your POST, serve captcha, and ask you to fill the POST again? Or
 accept your 10meg upload, serve captcha and ask you to upload it again?
 Now think about proxy behaviour during an attack. Doing captcha validation
 on POST is not a trivial thing.
 CloudFlare is in a position to inject JavaScript into sites. Why not hook
 requests that would result in a POST and challenge after say, clicking the
 submit button?

 >
 > @willscott:
 >
 > > What sort of data would qualify as an 'i'm a human' bit?
 >
 > Let's start with something not-worse than now: a captcha solved in last
  minutes.
 Is this something that CloudFlare has actually found effective? Are there
 metrics on how many challenged requests that successfully solved a CAPTCHA
 turned out to actually be malicious?

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 {{{
  What sort of data would qualify as an 'i'm a human' bit?
 }}}


 Does it even matter? Most bots, all the crawlers, sites like archive.is,
 etc are all regularly allowed in on Cloudflare sites.

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 Replying to [comment:9 cypherpunks]:
 > CloudFlare grew out of the narcs at Crimeflare. Do not assume good
 faith.

 That's right.


 {{{
 Substantial work with government and law enforcement officials
 }}}

 
[[Image(https://trac.torproject.org/projects/tor/attachment/ticket/18361/CloudFlareNarc.gif)]]

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by marek):

 @ioerror: you are doing this again. You are mixing your opinions with
 technical reality. Please stop insulting me. Please focus on what can we
 can technically do to fix the problem.

 > Here is a non-cryptographic, non-cookie based solution: Never prompt for
 a CAPTCHA on GET requests.

 There are a number of problems with this model.

 (POST is hard) First, what actually the proxy should *do* on the POST?
 Abort your POST, serve captcha, and ask you to fill the POST again? Or
 accept your 10meg upload, serve captcha and ask you to upload it again?
 Now think about proxy behaviour during an attack. Doing captcha validation
 on POST is not a trivial thing.

 (blocking regions) Second, during an "attack" (call it ddos or something)
 the website owners often decide to block traffic from ceirtain regions.
 Many businesses care only about visitors from some geographical region,
 and in case of a DDoS are happy to just DROP traffic from other regions.
 This is not something to like or dislike. This is a reality for many
 website owners. Serving captcha is strictly better than disallowing the
 traffic unconditionally.

 (Not only spam, load as well) Third, there regularly are bot "attacks"
 that just spam website with continous flood of GET requests, for example
 to check if the offered product is released, the promotion started or
 price updated. This is a problem for some website owners and they wish to
 allow only traffic from vetted sessions.

 The underlying problem, is that for any ddos / spam protection system the
 source IP address is a very strong signal. Unfortunately many Tor exit
 IP's have bad IP reputation, because they _ARE_ often used for unwanted
 activity.

 @willscott:

 > What sort of data would qualify as an 'i'm a human' bit?

 Let's start with something not-worse than now: a captcha solved in last
  minutes.

 > This sounds very much like something that could be provided through the
 use of zero-knowledge proofs

 Yup. What do we do to implement one both on ddos protection side and on
 TBB side?

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by cypherpunks):

 CloudFlare grew out of the narcs at Crimeflare. Do not assume good faith.

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--
Changes (by yawning):

 * cc: isis (added)


Comment:

 cc-ing isis since this covers earlier work.

 Replying to [comment:1 marek]:
 > Disclaimer: I work for CloudFlare. Disclaimer: Comments here are
 opinions of myself, not my employer.
 >
 > I will restrain myself and not comment on the political issues Jacob
 raised. I'll keep it technical.
 >
 > > I would like to find a solution with Cloudflare - but I'm unclear that
 the correct answer is to create a single cookie that is shared across all
 sessions - this effectively links all browsing for the web.
 >
 > A thousand times yes. I raised this option a couple times (supercookie)
 and we agreed this is a bad idea. I believe there is a cryptographic
 solution to this. I'm not a crypto expert, so I'll allow others to explain
 this. Let's define a problem:
 >
 > > There are CDN/DDoS companies in the internet that provide spam
 protection for their customers. To do this they use captchas to prove that
 the visitor is a human. Some companies provide protection to many
 websites, therefore visitor from abusive IP address will need to solve
 captcha on each and all domains protected. Let's assume the CDN/DDoS don't
 want to be able to correlate users visiting multiple domains. Is it
 possible to prove that a visitor is indeed human, once, but not allow the
 CDN/DDoS company to deanonymize / correlate the traffic across many
 domains?
 >
 > In other words: is it possible to provide a bit of data (i'm-a-human)
 tied to the browsing session while not violating anonymity.

 Yes.  This is a problem that "Anonymous Credential" systems are designed
 to solve.  A example of a system with most of the properties that are
 desired is presented in Au, M. H., Kapadia, A., Susilo, W., "BLACR: TTP-
 Free Blacklistable Anonymous Credentials with Reputation"
 (https://www.cs.indiana.edu/~kapadia/papers/blacr-ndss-draft.pdf).  Note
 that this is still an active research area, and BLACR it of itself may not
 be practical/feasible to implement, and is listed only as an example since
 the paper gives a good overview of the problem and how this kind of
 primitive can be used to solve the problem.

 Isis can go into more details on this sort of thing, since she was trying
 to implement a similar thing based on Mozilla Persona (aborted attempt due
 to Mozilla Persona being crap).

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ioerror):

 Ultimately, I wonder if the point is simply to identify people - across
 browser sessions, across proxies, across Tor exits - and the start is the
 "I'm a human bit" - I wonder where does that end?

 In a sense, I feel like this CF issue is like a giant Wifi Captive Portal
 for the web. It shims in some kind of "authentication" in a way that
 breaks many existing protocols and applications.

 If I was logged into Google (as they use a Google Captcha...), could they
 vouch for my account and auto solve it? Effectively creating an ID system
 for the entire web where CF is the MITM for all the users visiting users
 cached/terminated by them? I think - yes to both - and that is concerning.

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by sordid):

 > What sort of data would qualify as an 'i'm a human' bit?

 I don't think DDoS should be based on identifying humans.

 Bots are legitimate consumers of data as well, and in the future they
 might even be more intelligent that most humans today, so we might as well
 design our systems to be friendly for them.

 DDoS is a supply/demand type of economic issue and any solutions should
 treat it as such.

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by willscott):

 Replying to [comment:1 marek]:
 > > There are CDN/DDoS companies in the internet that provide spam
 protection for their customers. To do this they use captchas to prove that
 the visitor is a human. Some companies provide protection to many
 websites, therefore visitor from abusive IP address will need to solve
 captcha on each and all domains protected. Let's assume the CDN/DDoS don't
 want to be able to correlate users visiting multiple domains. Is it
 possible to prove that a visitor is indeed human, once, but not allow the
 CDN/DDoS company to deanonymize / correlate the traffic across many
 domains?
 >
 > In other words: is it possible to provide a bit of data (i'm-a-human)
 tied to the browsing session while not violating anonymity.
 >
 >
 This sounds very much like something that could be provided through the
 use of zero-knowledge proofs. It doesn't seem clear to me that being able
 to say "this is an instance of tor which has already answered a bunch of
 captcha's" is actually useful. I think the main problem with captchas at
 this point is that robots are just about as good at answering them as
 humans. Apparently robots are worse than humans at building up tracked
 browser histories. That seems like a harder property for a tor user to
 prove.

 What sort of data would qualify as an 'i'm a human' bit?

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--
Changes (by ioerror):

 * cc: arthuredelstein (added)


--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--
Changes (by ioerror):

 * cc: arthuredelstein (removed)


Comment:

 Replying to [comment:1 marek]:
 > Disclaimer: I work for CloudFlare. Disclaimer: Comments here are
 opinions of myself, not my employer.
 >

 Could you please ask your employer or other coworkers to come and talk
 with us openly? Many members of our community, some which are also your
 (server side) users, are extremely frustrated. It is in the best interest
 of everyone to help find a solution for those users.

 > I will restrain myself and not comment on the political issues Jacob
 raised. I'll keep it technical.
 >

 What specifically is political versus technical? That CF is now a GAA?
 That CF does indeed gather metrics? That CF does run untrusted (by me, or
 other users) in our browsers? That your metrics count as a kind of
 surveillance that is seemingly linked with a PRISM provider?

 > > I would like to find a solution with Cloudflare - but I'm unclear that
 the correct answer is to create a single cookie that is shared across all
 sessions - this effectively links all browsing for the web.
 >
 > A thousand times yes. I raised this option a couple times (supercookie)
 and we agreed this is a bad idea.

 What is the difference between one super cookie and ~1m cookies on a per
 site basis? The anonymity set appears to be *strictly* worse. Or do you
 guys not do any stats on the backend? Do you claim that you can't and
 don't link these things?

 > I believe there is a cryptographic solution to this. I'm not a crypto
 expert, so I'll allow others to explain this. Let's define a problem:

 >
 > > There are CDN/DDoS companies in the internet that provide spam
 protection for their customers. To do this they use captchas to prove that
 the visitor is a human. Some companies provide protection to many
 websites, therefore visitor from abusive IP address will need to solve
 captcha on each and all domains protected. Let's assume the CDN/DDoS don't
 want to be able to correlate users visiting multiple domains. Is it
 possible to prove that a visitor is indeed human, once, but not allow the
 CDN/DDoS company to deanonymize / correlate the traffic across many
 domains?

 Here is a non-cryptographic, non-cookie based solution: Never prompt for a
 CAPTCHA on GET requests.

 For such a user - how will you protect any information you've collected
 from them? Will that information be of higher value or richer technical
 information if there is a cookie (super, regular, whatever) tied to that
 data?

 > In other words: is it possible to provide a bit of data (i'm-a-human)
 tied to the browsing session while not violating anonymity.

 This feels like a trick question - behavioral analysis is in itself
 reducing the anonymity set by adding at least one bit of information. My
 guess is that it is a great deal more than a single bit - especially over
 time.

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (added)


--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor Browser   |Version:
 Severity:  Critical  | Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by marek):

 Disclaimer: I work for CloudFlare. Disclaimer: Comments here are opinions
 of myself, not my employer.

 I will restrain myself and not comment on the political issues Jacob
 raised. I'll keep it technical.

 > I would like to find a solution with Cloudflare - but I'm unclear that
 the correct answer is to create a single cookie that is shared across all
 sessions - this effectively links all browsing for the web.

 A thousand times yes. I raised this option a couple times (supercookie)
 and we agreed this is a bad idea. I believe there is a cryptographic
 solution to this. I'm not a crypto expert, so I'll allow others to explain
 this. Let's define a problem:

 > There are CDN/DDoS companies in the internet that provide spam
 protection for their customers. To do this they use captchas to prove that
 the visitor is a human. Some companies provide protection to many
 websites, therefore visitor from abusive IP address will need to solve
 captcha on each and all domains protected. Let's assume the CDN/DDoS don't
 want to be able to correlate users visiting multiple domains. Is it
 possible to prove that a visitor is indeed human, once, but not allow the
 CDN/DDoS company to correlate the traffic?

 In other words: is it possible to provide a bit of data tied to the
 browsing session while not violating anonymity.

--
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] #18360 [Tor]: option not to use mman-win32

[Tor Bug Tracker & Wiki]

#18360: option not to use mman-win32
+--
 Reporter:  erchewin|  Owner:
 Type:  enhancement | Status:  new
 Priority:  Low |  Milestone:  Tor:
Component:  Tor |  0.2.9.x-final
 Severity:  Minor   |Version:
 Keywords:  mman-win32, tor-core, easy  | Resolution:
Parent ID:  |  Actual Points:
  Sponsor:  | Points:
+--
Changes (by yawning):

 * priority:  Medium => Low
 * keywords:  mman-win32 => mman-win32, tor-core, easy
 * component:  - Select a component => Tor
 * severity:  Normal => Minor
 * milestone:   => Tor: 0.2.9.x-final


--
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] #18359 [Tor]: Implement "/ssl" option to HiddenService routing.

[Tor Bug Tracker & Wiki]

#18359: Implement "/ssl" option to HiddenService routing.
-+--
 Reporter:  ikurua22 |  Owner:
 Type:  enhancement  | Status:  new
 Priority:  Very Low |  Milestone:  Tor: unspecified
Component:  Tor  |Version:  Tor: unspecified
 Severity:  Minor| Resolution:
 Keywords:  tor-hs   |  Actual Points:
Parent ID:   | Points:
  Sponsor:   |
-+--
Changes (by yawning):

 * severity:  Normal => Minor
 * component:  - Select a component => Tor
 * priority:  Medium => Very Low
 * version:   => Tor: unspecified
 * milestone:   => Tor: unspecified
 * keywords:   => tor-hs
 * type:  project => enhancement


Comment:

 What's the point, links to HSes are already encrypted/authenticated.
 Beyond that, this feels like feature creep.  If people want to use TLS
 with a HS, the server that they're connecting to should be responsible for
 terminating TLS, not the tor instance.

 IMO `wontfix`, in that it will add a non-trivial amount of code, to do
 something (poorly, since this will scale like crap for now) that
 ultimately shouldn't be the tor daemon's responsibility.

--
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] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
-+--
 Reporter:  ioerror  |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Tor Browser  |Version:
 Severity:  Critical |   Keywords:  security, privacy, anonymity
Actual Points:   |  Parent ID:
   Points:   |Sponsor:
-+--
 There are companies - such as CloudFlare - which are effectively now
 Global Active Adversaries. Using CF as an example - they do not appear
 open to working together in open dialog, they actively make it nearly
 impossible to browse to certain websites, they collude with larger
 surveillance companies (like Google), their CAPTCHAs are awful, they block
 members of our community on social media rather than engaging with them
 and frankly, they run untrusted code in millions of browsers on the web
 for questionable security gains.

 It would be great if they allowed GET requests - for example - such
 requests should not and generally do not modify server side content. They
 do not do this - this breaks the web in so many ways, it is incredible.
 Using wget with Tor on a website hosted by CF is... a disaster. Using Tor
 Browser with it - much the same. These requests should be idempotent
 according to spec, I believe.

 I would like to find a solution with Cloudflare - but I'm unclear that the
 correct answer is to create a single cookie that is shared across all
 sessions - this effectively links all browsing for the web. When tied with
 Google, it seems like a basic analytics problem to enumerate users and
 most sites visited in a given session.

 One way - I think - would be to create a warning page upon detection of a
 CF edge or captcha challenge. This could be similar to an SSL/TLS warning
 dialog - with an option for users to bypass, engage with their systems or
 an option to *contact them* or the *site's owners* or to hit a cached
 version, read only version of the website that is on archive.org,
 archive.is or other caching systems. That would ensure that *millions* of
 users would be able to engage with informed consent before they're tagged,
 tracked and potentially deanonymized. TBB can protect against some of this
 - of course - but when all your edge nodes are run by one organization
 that can see plaintext, ip addresses, identifiers and so on - the
 protection is reduced. It is an open research question how badly it is
 reduced but intuitively, I think there is a reduction in anonymity.

 It would be great to find a solution that allows TBB users to use the web
 without changes on our end - where they can solve one captcha, if required
 - perhaps not even prompting for GET requests, for example. Though in any
 case - I think we have to consider that there is a giant amount of data at
 CF - and we should ensure that it does not harm end users. I believe CF
 would share this goal if we explain that we're all interested in
 protecting users - both those hosting and those using the websites.

 Some open questions:
 * What kind of per browser session tracking is actually happening?
 * What other options do we have on the TBB side?
 * What would a reasonable solution look like for a company like
 Cloudflare?
 * What is reasonable for a user to do? (~17 CAPTCHAs for one site == not
 reasonable)
 * Would "Warning this site is under surveillance by Cloudflare" be a
 reasonable warning or should we make it more general?

--
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] #18177 [DocTor]: Check Fallback Directory IPv4 and IPv6 addresses using DocTor

[Tor Bug Tracker & Wiki]

#18177: Check Fallback Directory IPv4 and IPv6 addresses using DocTor
-+--
 Reporter:  teor |  Owner:  atagar
 Type:  enhancement  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  DocTor   |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
  Sponsor:   |
-+--

Comment (by atagar):

 > In #16774, we added the fallback directories to GETINFO defaults. Tor
 0.2.8.1-alpha and later should be able to tell stem the fallback
 directories this way as well.

 That's fine. But this implementation doesn't require an active tor
 instance. For DocTor and other scripts dealing with descriptors having a
 tor process is an unnecessary hassle.

 > That's not good, can doctor please report any fallback directories that
 take a relatively long amount of time to serve a consensus (like doctor
 does for the authorities), and report any that take more than 10 seconds?

 I doubt Nick wants a ticket every time a fallback directory is sluggish.
 If you're interested in avoiding slow fallback directories any reason not
 to simply run the script I gave above when picking them?

--
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] #18177 [DocTor]: Check Fallback Directory IPv4 and IPv6 addresses using DocTor

[Tor Bug Tracker & Wiki]

#18177: Check Fallback Directory IPv4 and IPv6 addresses using DocTor
-+--
 Reporter:  teor |  Owner:  atagar
 Type:  enhancement  | Status:  reopened
 Priority:  Medium   |  Milestone:
Component:  DocTor   |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
  Sponsor:   |
-+--
Changes (by teor):

 * status:  closed => reopened
 * resolution:  implemented =>


Comment:

 Replying to [comment:8 atagar]:
 > Thanks teor! Done, but with a lot of
 
[https://gitweb.torproject.org/stem.git/commit/?id=332ef6e6fe89d9f0d48e9b95acff7de9f3ec647f
 expansion over what you asked]. Stem now has a FallbackDirectory class
 with two methods for getting this information...
 >
 > *
 
[https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.FallbackDirectory.from_remote
 FallbackDirectory.from_remote()] reads the latest fallback_dirs.inc from
 gitweb, providing the latest fallback directories in tor's master branch.
 >
 > *
 
[https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.FallbackDirectory.from_cache
 FallbackDirectory.from_cache()] provides the latest fallback directories
 Stem has cached. This is only as up-to-date as your Stem release but is
 quicker and avoids relying on gitweb.

 In #16774, we added the fallback directories to GETINFO defaults. Tor
 0.2.8.1-alpha and later should be able to tell stem the fallback
 directories this way as well.

 > * Stem's descriptor.remote module now puts less load on the directory
 authorities since it uses fallback directories as well.

 FYI, tor currently tries to connect to 3 fallback directories in the first
 few seconds, then tries an authority. It downloads from the first one that
 connects, and cancels the others. See #4483.

 > Downloading the consensus took 30.80 from eriador

 That's not good, can doctor please report any fallback directories that
 take a relatively long amount of time to serve a consensus (like doctor
 does for the authorities), and report any that take more than 10 seconds?

 How can I get on a list that gets this output, or will it appear on IRC in
 #tor-bots?

--
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] #18360 [- Select a component]: option not to use mman-win32

[Tor Bug Tracker & Wiki]

#18360: option not to use mman-win32
--+
 Reporter:  erchewin  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  mman-win32
Actual Points:|  Parent ID:
   Points:|Sponsor:
--+
 Tor can be compiled without mman-win32, because it has own implementation
 of mmap using Windows API. I want to explore this ability, but Tor uses
 mman-win32 if it is installed. I need an option --disable-mman-win32 of
 ./configure.

--
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] #18356 [Tor]: obfs4proxy cannot bind to <1024 port with systemd hardened service unit

[Tor Bug Tracker & Wiki]

#18356: obfs4proxy cannot bind to <1024 port with systemd hardened service unit
-+-
 Reporter:  irregulator  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
Component:  Tor  |  unspecified
 Severity:  Normal   |Version:  Tor:
 Keywords:  obfs4proxy, systemd, jessie, tor-pt  |  0.2.7.6
Parent ID:   | Resolution:
  Sponsor:   |  Actual Points:
 | Points:
-+-
Changes (by yawning):

 * priority:  Medium => Low
 * keywords:  obfs4proxy, systemd, jessie => obfs4proxy, systemd, jessie,
 tor-pt
 * component:  Obfsproxy => Tor
 * milestone:   => Tor: unspecified


Comment:

 Yes, the root cause is indeed how systemd is spawning tor, and the config
 option.  There is absolutely nothing I can do from within obfs4proxy to
 work around this, because it is a security feature enforced by the kernel.

 Something like the tor daemon opening the socket bound to a privileged
 port would be possible, but that requires patching tor, modifying the PT
 configuration/spawn process, and then modifying obfs4proxy.

 Since "fixing" this requires modifying the service file at a minimum, and
 a large list of tor changes and spec changes to do correctly, I am re-
 categorizing this.

--
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] #18177 [DocTor]: Check Fallback Directory IPv4 and IPv6 addresses using DocTor

[Tor Bug Tracker & Wiki]

#18177: Check Fallback Directory IPv4 and IPv6 addresses using DocTor
-+-
 Reporter:  teor |  Owner:  atagar
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  DocTor   |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
  Sponsor:   |
-+-
Changes (by atagar):

 * status:  new => closed
 * resolution:   => implemented


Comment:

 Thanks teor! Done, but with a lot of
 
[https://gitweb.torproject.org/stem.git/commit/?id=332ef6e6fe89d9f0d48e9b95acff7de9f3ec647f
 expansion over what you asked]. Stem now has a FallbackDirectory class
 with two methods for getting this information...

 *
 
[https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.FallbackDirectory.from_remote
 FallbackDirectory.from_remote()] reads the latest fallback_dirs.inc from
 gitweb, providing the latest fallback directories in tor's master branch.

 *
 
[https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.FallbackDirectory.from_cache
 FallbackDirectory.from_cache()] provides the latest fallback directories
 Stem has cached. This is only as up-to-date as your Stem release but is
 quicker and avoids relying on gitweb.

 Advantages are...

 * Stem's descriptor.remote module now puts less load on the directory
 authorities since it uses fallback directories as well.

 * Much, much easier to add further scripts that take advantage of the
 fallback directories.

 * Running Stem's integ tests with the ONLINE target includes a test that
 exercises all the fallback directories, notifying us if any are down.

 Here's an example script to check the performance of the fallback
 directories...

 {{{
 import time
 from stem.descriptor.remote import DescriptorDownloader, FallbackDirectory

 downloader = DescriptorDownloader()

 for fallback_directory in FallbackDirectory.from_cache().values():
   start = time.time()
   downloader.get_consensus(endpoints = [(fallback_directory.address,
 fallback_directory.dir_port)]).run()
   print('Downloading the consensus took %0.2f from %s' % (time.time() -
 start, fallback_directory.nickname))
 }}}

 {{{
 % python example.py
 Downloading the consensus took 5.07 from Doedel22
 Downloading the consensus took 3.59 from tornoderdednl
 Downloading the consensus took 4.16 from Logforme
 Downloading the consensus took 6.76 from Doedel21
 Downloading the consensus took 5.21 from kitten4
 Downloading the consensus took 3.25 from kili
 Downloading the consensus took 4.23 from wagner
 Downloading the consensus took 3.30 from BabylonNetwork03
 Downloading the consensus took 3.50 from kitten2
 Downloading the consensus took 3.31 from coby
 Downloading the consensus took 5.61 from GrmmlLitavis
 Downloading the consensus took 5.05 from Doedel24
 Downloading the consensus took 3.60 from BabylonNetwork02
 Downloading the consensus took 3.61 from Unnamed
 Downloading the consensus took 2.71 from Binnacle
 Downloading the consensus took 30.80 from eriador
 Downloading the consensus took 6.91 from Doedel26
 Downloading the consensus took 3.30 from fluxe4
 Downloading the consensus took 3.16 from PedicaboMundi
 Downloading the consensus took 3.33 from kitten1
 Downloading the consensus took 3.39 from fluxe3
 }}}

 Feel free to reopen if you need anything else.

--
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] #17303 [DirAuth]: Bad exits inject port 8123 into HTTP redirects

[Tor Bug Tracker & Wiki]

#17303: Bad exits inject port 8123 into HTTP redirects
--+--
 Reporter:  ikurua22  |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  DirAuth   |Version:  Tor: unspecified
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
  Sponsor:|
--+--

Comment (by ikurua22):

 How about adding this detection to Tor itself, and force users to use
 latest Tor(kick out old version)?

--
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] #18359 [- Select a component]: Implement "/ssl" option to HiddenService routing.

[Tor Bug Tracker & Wiki]

#18359: Implement "/ssl" option to HiddenService routing.
--+-
 Reporter:  ikurua22  |  Owner:
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|Sponsor:
--+-
 HiddenServicePort 443/ssl 10.20.30.40:80
 HiddenServiceTLScert /path/to/file/cert
 HiddenServiceTLSpkey /path/to/file/secret

 User: httpS://abc.de/
 Tor: 443-->decrypt-->80
 Web: 80.

--
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] #18358 [Tor]: Tor Browser is tracking user activity by sending .onion names.

[Tor Bug Tracker & Wiki]

#18358: Tor Browser is tracking user activity by sending .onion names.
--+-
 Reporter:  ikurua22  |  Owner:
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Tor   |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|Sponsor:
--+-
 By using default Tor Browser Bundle, you are leaking xxx.onion to
 torproject blindly.
 By looking at torrc, you will notice TBB will report xxx.onion without
 notice, you must change its setting to not reporting statics.

 I am using x.onion as my private webcamera(protected by its password
 AND Tor's HidServAuth), and I DO NOT want Tor and other people
 to visit my x.onion WITHOUT my authorization!

--
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] #18357 [Tor]: HiddenServicePort IPv6 broken on FreeBSD

[Tor Bug Tracker & Wiki]

#18357: HiddenServicePort IPv6 broken on FreeBSD
+---
 Reporter:  sega01  |  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Tor |Version:  Tor: 0.2.6.10
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |Sponsor:
+---
 Hi,

 In reference to: #6551 and #12670.

 I was not having much luck setting up a Hidden Service. I found later that
 worked when I used 127.0.0.1:80 instead of [::1]:80.

 I then tested v6 and v4, side-by-side:
 HiddenServicePort 80 127.0.0.1:80
 HiddenServicePort 81 [::1]:80

 Port 80 worked, 81 did not. I checked a few times with curl locally and
 with tor browser.

 I'm running FreeBSD 10.2. Had a pretty slim configuration when I tried
 this. Verified with fetch and sockstat that indeed the service was
 listening on ::1 (::0/0, actually).

 Thank you,
 Teran

--
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] #18356 [Obfsproxy]: obfs4proxy cannot bind to <1024 port with systemd hardened service unit

[Tor Bug Tracker & Wiki]

#18356: obfs4proxy cannot bind to <1024 port with systemd hardened service unit
-+-
 Reporter:  irregulator  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfsproxy|Version:  Tor: 0.2.7.6
 Severity:  Normal   |   Keywords:  obfs4proxy, systemd, jessie
Actual Points:   |  Parent ID:
   Points:   |Sponsor:
-+-
 Hi,

 I was running an obfs4proxy Debian Wheezy bridge with such configuration
 in torrc:


 {{{
 ServerTransportListenAddr obfs4 0.0.0.0:443
 }}}

 When I dist-upgraded to Debian Jessie, obfs4proxy could not bind to :443
 any more, while tor logs had such messages:


 {{{
 Feb 21 22:51:09.000 [warn] Server managed proxy encountered a method
 error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied)
 Feb 21 22:51:09.000 [warn] Managed proxy at '/usr/bin/obfs4proxy' failed
 the configuration protocol and will be destroyed.
 }}}

 Mind that I have already set the appropriate capability to the obfs4proxy
 binary:

 {{{
 getcap /usr/bin/obfs4proxy
 /usr/bin/obfs4proxy = cap_net_bind_service+ep
 }}}

 I took some time moving things around and I think the problem resides on
 the systemd service unit:
 https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in and
 specifically the option introduced in
 b4170421cc58d8c57254f4224ba259e817f48869 .

 {{{
 NoNewPrivileges=yes
 }}}

 I assume so because flipping 'NoNewPrivileges=no' results in obfs4proxy
 binding to 443. Also, 'PR_SET_NO_NEW_PRIVS' section in 'man 2 prctl'
 implies so:

 {{{
 PR_SET_NO_NEW_PRIVS (since Linux 3.5)
   Set  the  calling  process's  no_new_privs  bit to the value
 in arg2.  With
   no_new_privs set to 1, execve(2) promises not to  grant
 privileges  to  do
   anything  that  could  not  have  been done without the
 execve(2) call (for
   example, rendering the set-user-ID and set-group-ID
 permission  bits,  and
   file  capabilities  non-functional).   Once  set, this bit
 cannot be unset.
   The setting of this bit is inherited by children  created
 by  fork(2)  and
   clone(2), and preserved across execve(2).

   For   more   information,   see   the   kernel   source
 file   Documenta‐
   tion/prctl/no_new_privs.txt.
 }}}

 I understand that 'NoNewPrivileges=no' is a system security drawback but I
 also consider a regression to not be able to bind obfs4proxy to ports
 <1024. Could we find a middle ground?


 If that helps, I'm running:

 {{{
 tor: 0.2.7.6-1~d80.jessie+1
 deb.torproject.org/torproject.org/ jessie/main amd64 Packages

 obfs4proxy: 0.0.4-1~tpo1
 deb.torproject.org/torproject.org/ obfs4proxy/main amd64 Packages
 }}}

 Also:

 {{{
 cat /etc/debian_version
 8.3
 cat /proc/version
 Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version
 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17)
 }}}

 Thanks for your work.

--
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] #12595 [Tor]: Finalize design for improved guard-node behavior

[Tor Bug Tracker & Wiki]

#12595: Finalize design for improved guard-node behavior
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 Priority:  High |  assigned
Component:  Tor  |  Milestone:  Tor:
 Severity:  Normal   |  0.2.9.x-final
 Keywords:  tor-guard, TorCoreTeam201509,|Version:  Tor:
  028-triaged, mike-can  |  0.2.7
Parent ID:   | Resolution:
  Sponsor:  SponsorU |  Actual Points:
 | Points:  medium
-+-
Changes (by asn):

 * milestone:  Tor: 0.2.8.x-final => Tor: 0.2.9.x-final


Comment:

 Progress is being done here but no way we can fit it in 0.2.8.

 Moving to next release.

--
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] #18355 [Metrics]: Tor version 0.2.4 and Other versions have the same color

[Tor Bug Tracker & Wiki]

#18355: Tor version 0.2.4 and Other versions have the same color
-+-
 Reporter:  karsten  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |Sponsor:
-+-
 Reported by ahf in #tor-dev on February 19, 2016.  Example:
 https://metrics.torproject.org/versions.html

 Possible fix could be to use gray for Other, because that line is always
 in the graph, and keep using colors for actual versions.

 Another alternative could be to switch to a faceted plot with multiple
 time plots beneath each other.  That would make it a bit harder to compare
 absolute numbers, but it would also remove the problem of colors behind
 difficult to distinguish.

 Or maybe there are even smarter visualizations available?

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