Re: [tor-dev] Fact-checking a claim about relay/bridge fingerprint authentication

On Thu, Feb 15, 2024 at 10:54:22AM -0500, Roger Dingledine wrote: > > If possible, we'd still like confirmation of (1) whether this is a good > > characterization of the constraints involved when using a Tor bridge, > > and (2) if 4.2 is the right part of tor-spec to cite for clients > >

Re: [tor-dev] Fact-checking a claim about relay/bridge fingerprint authentication

only On Tue, Oct 03, 2023 at 08:44:39PM -0400, David Fifield wrote: > Cecylia, Arlo, Serene, Shelikhoo, and I are writing a research paper > about Snowflake. Here is a draft: > https://www.bamsoftware.com/papers/snowflake/snowflake.20231003.e6e1c30d.pdf > > We're writing to check

[tor-dev] Fact-checking a claim about relay/bridge fingerprint authentication

Cecylia, Arlo, Serene, Shelikhoo, and I are writing a research paper about Snowflake. Here is a draft: https://www.bamsoftware.com/papers/snowflake/snowflake.20231003.e6e1c30d.pdf We're writing to check a factual claim in the section about having multiple backend bridges. Basically, we wanted it

[tor-dev] PT bridge reporting significant numbers of IP addresses after upgrade to 0.4.8.6; Conflux related?

The Snowflake bridges do not expose their plain ORPort (they have `ORPort 127.0.0.1:auto` in torrc), and consequently they have always reported ≈0 IP addresses in the bridge-ip-transports line of bridge-extra-info descriptors, with virtually all connecting IP addresses being instead attributed to

Re: [tor-dev] Two features that would help load-balanced bridges

-hiperf.20230307.pdf https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.20230307.tex On Mon, Feb 07, 2022 at 07:26:37PM -0700, David Fifield wrote: > After the blocking of Tor in Russia in December 2022, the number of > Snowflake users rapidly increased. Eventually the tor p

[tor-dev] goptlib moved to gitlab.torproject.org

I have moved the goptlib repository from git.torproject.org to gitlab.torproject.org. If you want to use it at the new location, change this import: import "git.torproject.org/pluggable-transports/goptlib.git" to this: import

[tor-dev] Cross-user TLS traffic mixing in snowflake-server until 2023-03-13

Between 2022-10-01 and 2023-03-13, there was a bug in the software deployed at Snowflake bridges that could cause parts of a user's stream to be overwritten by parts of other users' streams. Though the Snowflake team believes the privacy risks of the bug are minor, we are treating it as a security

Re: [tor-dev] Is Arti expected to have better multi-CPU support than C-tor?

On Wed, Mar 08, 2023 at 06:30:42AM -0500, Nick Mathewson wrote: > On Tue, Mar 7, 2023 at 4:07 PM David Fifield <[1]da...@bamsoftware.com> wrote: > > Linus Nordberg and I are preparing a submission for FOCI about the > special way we run tor on the Snowflake bridg

[tor-dev] Is Arti expected to have better multi-CPU support than C-tor?

Linus Nordberg and I are preparing a submission for FOCI about the special way we run tor on the Snowflake bridge. We run many tor processes with the same identity and onion keys, because otherwise tor being limited to one CPU would be the main bottleneck. I'm writing to fact-check a claim about

Re: [tor-dev] Metrics: Estimating fraction of reported directory-request statistics

On Thu, Apr 21, 2022 at 05:47:12PM +0200, Silvia/Hiro wrote: > On 17/4/22 2:16, David Fifield wrote: > > I am trying to reproduce the "frac" computation from the Reproducible > > Metrics instructions: > > https://metrics.torproject.org/reproducible-metrics.htm

Re: [tor-dev] Metrics: Estimating fraction of reported directory-request statistics

On Mon, Apr 18, 2022 at 03:45:29PM -0600, David Fifield wrote: > I was initially interested in this for the purpose of better estimating > the number of Snowflake users. But now I've decided "frac" is not useful > for that purpose: since there is only one bridge we care about,

Re: [tor-dev] Metrics: Estimating fraction of reported directory-request statistics

On Sat, Apr 16, 2022 at 06:16:23PM -0600, David Fifield wrote: > I am trying to reproduce the "frac" computation from the Reproducible > Metrics instructions: > https://metrics.torproject.org/reproducible-metrics.html#relay-users > Which is also Section 3 in the tech rep

[tor-dev] Metrics: Estimating fraction of reported directory-request statistics

I am trying to reproduce the "frac" computation from the Reproducible Metrics instructions: https://metrics.torproject.org/reproducible-metrics.html#relay-users Which is also Section 3 in the tech report on counting bridge users:

[tor-dev] Two features that would help load-balanced bridges

After the blocking of Tor in Russia in December 2022, the number of Snowflake users rapidly increased. Eventually the tor process became the limiting factor for performance, using all of one CPU core. In a thread on tor-relays, we worked out a design where we run multiple instances of tor on the

Re: [tor-dev] GSoC 2021 - Alexa Top Sites Captcha and Tor Block Monitoring #Update

On Mon, Jul 12, 2021 at 05:01:35PM +0530, Apratim Ranjan Chakrabarty wrote: > ** Looking forward for suggestions and comments as to how to improve on it. > Also materials like research paper in this domain would be helpful ** Section IV-C of the ICLab paper has discussion of block page detection.

Re: [tor-dev] Uptime stats for "Tor user can access an otherwise-functional hidden service"?

On Wed, May 05, 2021 at 03:27:23PM -0400, Holmes Wilson wrote: > 3. Is there some incident log somewhere of problems that affected > onion services network wide that includes how long these problems > persisted for? (I don't see any onion service outage notes in this > document, though I seem to

Re: [tor-dev] Tails vs the capacity of the Meek bridges

On Fri, Mar 20, 2020 at 11:51:41AM +0100, anonym wrote: > tl;dr: if Tails makes it too easy to use Meek bridges, could it overload the > current set of Meek bridges? The default meek bridge is already overloaded, unfortunately. Users complain that even though it works, it is too slow. Reports of

Re: [tor-dev] Shortcomings of the pluggable transports specification?

On Wed, Jun 12, 2019 at 04:41:34PM -0700, Philipp Winter wrote: > We are working on improving Tor's pluggable transports specification: > > > The goal is to make the spec useful to more people and fix issues that > have accumulated over the years. For more

Re: [tor-dev] Release: obfs4proxy-0.0.10

On Sat, May 04, 2019 at 03:27:53PM +, Yawning Angel wrote: > On 5/3/19 1:48 PM, Steve Snyder wrote: > > FYI, obfs4proxy no longer recognizes address:port in this form: > > > > ServerTransportListenAddr obfs4 [000.000.000.000]:443 > > > > Note the square brackets. Tor 0.3.5.8 / 0.4.0.5

[tor-dev] ICLab testing of default bridges

At the anti-censorship meeting today you mentioned talking to ICLab about testing the default bridges. I believe that ICLab is already testing at least a portion of the default bridges; they may have data that you just have to ask for. OONI and ICLab test the default bridges as a result of my,

Re: [tor-dev] using obfs4 to tunnel to a SOCKS proxy server

On Fri, Jan 25, 2019 at 12:03:19AM +0100, Hans-Christoph Steiner wrote: > Is this the same with other PT 1.1 daemons? Or would Snowflake be > different? Seems like with obfs4, the load balancer using SNI would > probably be the easiest for the wikipedia use case. It will be the same with any

Re: [tor-dev] RFC: Using `utls` in meek_lite.

On Thu, Jan 24, 2019 at 07:44:48AM +, Yawning Angel wrote: > On 1/24/19 7:38 AM, David Fifield wrote: > > I see, you're right. It has to do with the reuse of the initConn. > > A proper "general" solution that solves that problem and the ALPN issue

Re: [tor-dev] RFC: Using `utls` in meek_lite.

On Thu, Jan 24, 2019 at 07:33:39AM +, Yawning Angel wrote: > On 1/24/19 6:47 AM, David Fifield wrote: > > // This also assumes that req.URL.Host will remain constant for the > > // lifetime of the roundTripper, which is a valid assumption for > > meeklite

Re: [tor-dev] RFC: Using `utls` in meek_lite.

On Mon, Jan 21, 2019 at 05:12:41AM +, Yawning Angel wrote: > I just pushed a change to obfs4proxy master to use `utls` to mask the > ClientHello signature (currently Chrome 70.x). > > https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3 // This also

Re: [tor-dev] using obfs4 to tunnel to a SOCKS proxy server

On Wed, Jan 23, 2019 at 11:41:42AM +, Yawning Angel wrote: > > For example, could the obfs4 server side provide a generic SOCKS proxy? > > There is no functionality for doing such a thing in mainline obfs4proxy. > > What currently will work is any one of: > > * Stick a proxy server of your

Re: [tor-dev] RFC: Using `utls` in meek_lite.

On Mon, Jan 21, 2019 at 05:12:41AM +, Yawning Angel wrote: > I just pushed a change to obfs4proxy master to use `utls` to mask the > ClientHello signature (currently Chrome 70.x). > > https://gitlab.com/yawning/obfs4/commit/4d453dab2120082b00bf6e63ab4aaeeda6b8d8a3 > > I understand that this

Re: [tor-dev] Dormant Mode and pluggable transports

On Fri, Dec 14, 2018 at 04:28:26AM +0100, Alexander Færøy wrote: > On Thu, Dec 13, 2018 at 04:15:56PM -0700, David Fifield wrote: > > If transports need to become dormant too, then there needs to be some > > way for tor to tell them to be. Now that https://bugs.torproject.org/28

[tor-dev] Dormant Mode and pluggable transports

On Thu, Dec 13, 2018 at 03:56:50PM -0500, Nick Mathewson wrote: > == Compatibility issues > > I see two issues here: one minor, and one major. > > Minor issue: some applications periodically make requests to the tor > network on their own -- for example, Tor Browser's update requests. > These

Re: [tor-dev] Failure to connect to a 0.3.4.9 bridge--downgrading to 0.2.9.17 fixes it

On Thu, Dec 06, 2018 at 10:19:09PM -0700, David Fifield wrote: > Here, a user reported a failure to connect to their own bridge, stopping > at 25% bootstrapped. teor and I went through the basic troubleshooting > steps of checking the bridge syntax, system time, and firewall

[tor-dev] Failure to connect to a 0.3.4.9 bridge--downgrading to 0.2.9.17 fixes it

Here, a user reported a failure to connect to their own bridge, stopping at 25% bootstrapped. teor and I went through the basic troubleshooting steps of checking the bridge syntax, system time, and firewall settings. With or without obfs4 didn't make a difference. The user eventually tried

Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports

On Sat, Oct 27, 2018 at 05:20:06PM +0530, Piyush Kumar Sharma wrote: > 3.) I searched a lot but could not find the timeline in which pluggable > transports were built. As in what was developed and deployed first, obfs4 or > meek? For questions like this, see our metrics timeline page:

Re: [tor-dev] Idea which may or may not of been discussed

On Sat, Oct 13, 2018 at 12:21:49PM -0400, Matt Traudt wrote: > Why wouldn't it be just as easy for censors to identify the small set of > registered domains that Tor relays use and block TLS connections that > involve them? And in general, IMO pluggable transports are the right layer to address

Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...

On Thu, Oct 04, 2018 at 09:37:18AM +0200, Andreas Krey wrote: > A quick search indicates that aws and azure are already > supporting it, although I'm unable to interpret whether that is > actually the respective product you are/were using. That's exactly it. Of course you can spin up a random EC2

Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...

On Wed, Oct 03, 2018 at 07:01:21PM -0600, David Fifield wrote: > And for that matter, why not a plain old HTTP CONNECT proxy? That would > be even more efficient. I should add that--leaving out domain fronting/encrypted SNI--there's an implementation of exactly this, a pluggable transport

Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...

On Mon, Oct 01, 2018 at 07:55:31PM +0200, Andreas Krey wrote: > On Mon, 24 Sep 2018 20:23:58 +0000, David Fifield wrote: > ... > > "encrypted SNI" part. But it's possible to do better: if you're willing > > to abandon HTTP/1.1 compatibility and require HTTP/2, you

Re: [tor-dev] Information on the handling of relays churn

On Thu, Sep 27, 2018 at 08:21:06PM +0200, Adrien Luxey wrote: > • To which extent would you say that Tor is resilient to churn? What would > be > the effects of a massive churn of relays? Where would be the bottleneck? About churn specifically, the Sybil research of Winter, Ensafi,

Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...

On Mon, Sep 24, 2018 at 01:46:10PM -0400, Nathaniel Suchy wrote: > What this means: > Effectively domain fronting works by sending a different SNI and host header. > CDN providers like Cloudflare started double checking to make governments > happy, scratch that line, I mean to protect their

Re: [tor-dev] Ready to Integrate/Review New Marionette Version into Tor

On Tue, Jul 24, 2018 at 01:57:36PM -0400, John Helmsen wrote: > Okay, I have generated a VM using VirtualBox of Ubuntu version 16.  I've had > to > restart the build process a couple of times, since the hard drive was 10GB, > then 20GB.  Now I am using a 50GB box, so it may work this time. > >

Re: [tor-dev] Ready to Integrate/Review New Marionette Version into Tor

On Tue, Jul 24, 2018 at 11:42:08AM -0400, John Helmsen wrote: > Thank you, I have created the ticket as #26920. https://trac.torproject.org/ > projects/tor/ticket/26920#ticket.  Having downloaded the git project, it seems > that this work cannot be performed on a Mac, since it doesn't run 'runc'. 

Re: [tor-dev] Ready to Integrate/Review New Marionette Version into Tor

On Fri, Jul 20, 2018 at 04:12:21PM -0400, John Helmsen wrote: > We are in the process of writing the documentation for Marionette, but the > documentation on the web page should be sufficient for at least getting a full > evaluation started.  We'd like to have the evaluation complete by the end of

Re: [tor-dev] man: "IPv6 addresses should be wrapped in square brackets"

On Sun, Jul 01, 2018 at 10:03:50AM +1000, teor wrote: > When an option only takes an IP address, it does not make a difference. > (As long as the underlying code uses tor_addr_parse().) BTW there's currently a bug relating to this: if an address starts with '[', tor_addr_parse strips the final

Re: [tor-dev] permission denied when running snowflake-client with debian-tor user

On Mon, Jun 11, 2018 at 07:30:31PM +, Yawning Angel wrote: > On Mon, 11 Jun 2018 13:24:19 -0400 > Arlo Breault wrote: > > When you launch the client binary without providing a broker url > > it tries to create a named pipe (mkfifo) to do signalling. > > > >

Re: [tor-dev] Connections failed to default obfs4 bridges

On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote: > In a recent connectivity test to the default obfs4 bridges [0], we found that > we are unable to connect to 10 or so of them (from open networks, i.e., no > local filtering). > > Is this a feature, like some of them only respond to

Re: [tor-dev] Pluggable transports research

On Wed, Jan 24, 2018 at 04:42:52PM -0800, Jodi Spacek wrote: > I'm a master's student at the University of British Columbia (Vancouver, > Canada) where I'm primarily researching anonymous systems and censorship. I > would be delighted to contribute to pluggable transports.  > > Of particular

Re: [tor-dev] Dir auths using 2x bandwidth in last week

On Sun, Sep 17, 2017 at 07:32:13PM -0400, Roger Dingledine wrote: > On Wed, Aug 09, 2017 at 11:36:27PM -0400, Roger Dingledine wrote: > > https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020CE31 > >

Re: [tor-dev] Dir auths using 2x bandwidth in last week

On Mon, Aug 21, 2017 at 01:56:16PM +1000, teor wrote: > > > On 10 Aug 2017, at 13:36, Roger Dingledine wrote: > > > > https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020CE31 > > https://atlas.torproject.org/#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281 >

Re: [tor-dev] Tor and IP2Location LITE

On Sun, Aug 20, 2017 at 10:02:20PM +0200, Karsten Loesing wrote: > Okay. Maybe we could do something with archive.org in that case. It's > not that we do have a complete history for MaxMind's files, except that > we could probably create our own history from Tor's Git repository which > contains

Re: [tor-dev] Feature Request: please consider ship default Tor bridges

On Thu, Aug 17, 2017 at 05:19:44PM +, iry wrote: > A set of Tor bridges are shipped with Tor browser bundle[0], helping > users in Tor-censored area to connection to the Tor network. Since > system Tor users may also face the censorship problem, shall we > ship some Tor bridges along with the

Re: [tor-dev] Pluggable Transports 2.0 Specification, Draft 2

On Wed, Jun 21, 2017 at 06:20:44AM +, Yawning Angel wrote: > On Tue, 20 Jun 2017 21:27:35 -0700 > David Fifield <da...@bamsoftware.com> wrote: > > Even closely affiliated projects like Orbot haven't been able to use > > pluggable transports strictly accord

Re: [tor-dev] Pluggable Transports 2.0 Specification, Draft 2

On Wed, Jun 21, 2017 at 01:16:20PM +1000, teor wrote: > In general, is there a separate document or proposal that describes > how Tor will implement the relevant interfaces? There doesn't seem > to be much on Tor-specific issues in this spec. > > There is one "Tor" note in the spec, maybe it

[tor-dev] The limits of timing obfuscation in obfs4

ree/doc/obfs4-spec.txt?id=obfs4proxy-0.0.7 From 3699bbda1633b17eb5fae9ced6158df42fe1384b Mon Sep 17 00:00:00 2001 From: David Fifield <da...@bamsoftware.com> Date: Sat, 10 Jun 2017 17:26:13 -0700 Subject: [PATCH] Queue writes through an independent write scheduler. Send padding pack

Re: [tor-dev] Default bridges that are not publishing statistics

On Mon, Jun 05, 2017 at 11:51:04PM +1000, teor wrote: > > Can you get logs (and torrcs) from those bridges to confirm whether > they think they are producing extra info descriptors? I've asked the operator but not gotten a reply yet. ___ tor-dev

Re: [tor-dev] Default bridges that are not publishing statistics

On Mon, Jun 05, 2017 at 03:15:08PM +1000, teor wrote: > > > On 5 Jun 2017, at 15:06, David Fifield <da...@bamsoftware.com> wrote: > > > > Calling get_extrainfo_descriptors from stem.descriptor.remote returns an > > empty list. (499D92E08769BFC0B7941C74031335B9E

Re: [tor-dev] Default bridges that are not publishing statistics

Thanks for your informative reply. On Mon, Jun 05, 2017 at 02:37:00PM +1000, teor wrote: > > > On 2 Jun 2017, at 08:20, David Fifield <da...@bamsoftware.com> wrote: > > > > ... > > And this Stem script: > > from stem.control import Controller > &

Re: [tor-dev] Default bridges that are not publishing statistics

On Wed, May 24, 2017 at 09:31:45PM -0700, David Fifield wrote: > On Sat, May 06, 2017 at 09:25:11AM -0700, David Fifield wrote: > > Okay, thanks. It still doesn't fully make sense to me, because while > > some of the default bridges are in Atlas, not all of them are (for > >

[tor-dev] Default bridges that are not publishing statistics

On Sat, May 06, 2017 at 09:25:11AM -0700, David Fifield wrote: > Okay, thanks. It still doesn't fully make sense to me, because while > some of the default bridges are in Atlas, not all of them are (for > example the two from https://bugs.torproject.org/21917). I don't think > i

Re: [tor-dev] Why is my bridge not publishing statistics?

On Sat, May 06, 2017 at 09:25:11AM -0700, David Fifield wrote: > > You're right that this is a fragile situation. Maybe we should recommend > > that if you firewall your ORPort, you also set "AssumeReachable 1" > > in your torrc? > > I've just set "Assu

Re: [tor-dev] Why is my bridge not publishing statistics?

On Sat, May 06, 2017 at 03:41:28AM -0400, Roger Dingledine wrote: > On Fri, May 05, 2017 at 04:30:52PM -0700, David Fifield wrote: > > But if it's the case that an unreachable ORPort causes descriptors not > > to be uploaded, then why do the default obfs4 bridges appear in Atlas?

[tor-dev] Why is my bridge not publishing statistics?

I searched for the Snowflake bridge in Atlas, and couldn't find it. Its fingerprint is 2B280B23E1107BB62ABFC40DDCC8824814F80A72. Its torrc is stock "Last updated 9 October 2013 for Tor 0.2.5.2-alpha" except for these settings: ContactInfo David Fifield <d...@t

[tor-dev] "firefox --app" for meek-http-helper

On Sun, Mar 26, 2017 at 02:28:00PM +, anonym wrote: > Tails uses the Tor Launcher shipped in Tor Browser, but it's run as a > stand-alone XUL application (`firefox --app ...`), so the *web* > browser isn't started as part of it. Sorry to change the subject, but should we be running

Re: [tor-dev] Flashproxy has been Deactivated by Stanford? Why?

On Mon, Dec 19, 2016 at 09:53:25AM -0800, David Fifield wrote: > The badge was deactivated by Stanford (without my knowledge, but I found > out a while ago). I arranged with them to move it to alternate hosting > and have them install a redirect, but that has been a low priority >

Re: [tor-dev] Flag blocked websites

On Fri, Mar 10, 2017 at 03:46:03PM -0500, Boter42 wrote: > I'm also trying to implement an automatic scan of specific lists of websites > to > check their behaviour towards Tor. I'm using ooniprobe but I lack some > technical skills (mainly to filter out false positives), I'll see if I can set >

Re: [tor-dev] Flag blocked websites

On Fri, Mar 10, 2017 at 08:27:01AM -0500, Boter42 wrote: > I think it would be important to have a way to flag/report those websites that > can't be access by the users while they're using the tor browser.  > > Is there already a solution to do this? Do you think it would be a good tool?  > > It

Re: [tor-dev] OnionGatherer: evaluating status of hidden services

On Fri, Mar 10, 2017 at 12:58:55PM +0100, Massimo La Morgia wrote: > we are a research group at Sapienza University, Rome, Italy. We do research on > distributed systems, Tor, and the Dark Web. As part of our work, we have > developed OnionGatherer, a service that gives up-to-date information

Re: [tor-dev] GAEuploader

On Sun, Jan 22, 2017 at 03:53:16PM -0800, Katherine Li wrote: > I would really appreciate user testing on GAEuploader. You can download it > at:  > https://github.com/katherinelitor/GAEuploader/releases > README: https://github.com/katherinelitor/GAEuploader > Tor wiki page, containing

Re: [tor-dev] Flashproxy has been Deactivated by Stanford? Why?

On Tue, Dec 20, 2016 at 01:21:04AM +0800, to...@riseup.net wrote: > It turned out that the entire code has been commented out and apparently > Flashproxy became > out of service. Why? Has the project discontinued, or just down for > maintenance? Flash proxy is basically retired now. It was

Re: [tor-dev] automatically detect many new identical/similar bridges

On Wed, Dec 14, 2016 at 10:09:00AM +, nusenu wrote: > in the context of [1] I'm wondering if it makes sense to add bridge > support to ornetradar. > > If there is any value to automatically detect multiple new bridges: > > - Do bridges publish ContactInfo in their descriptor? If not: Why

[tor-dev] Using fingerprint of cached relay bypasses bridge?

Someone on #tor-project IRC reported that you can bypass your pluggable transport if you use the fingerprint of an ordinary relay already known to Tor in your bridge line. I would file a ticket but I haven't been able to reproduce it. The example the IRC user gave was this, meant to be pasted

Re: [tor-dev] Call for help on testing core tor releases

On Thu, Oct 13, 2016 at 02:29:19PM -0400, isab...@riseup.net wrote: > Hello Tor community! > > The Core Tor Team would like to improve our release process by getting > it more tested so bugs are found earlier, so stable releases can get out > faster and without any big bugs. > > During Tor's

Re: [tor-dev] Tor Relays on Whonix Gateway

On Wed, Oct 19, 2016 at 10:35:16PM +0200, ban...@openmailbox.org wrote: > On 2016-10-17 10:24, isis agora lovecruft wrote: > > > > You're planning to enable "ServerTransportPlugin snowflake" on Whonix > > Gateways > > by default? And then "ClientTransportPluging snowflake" on workstations > >

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

On Fri, Oct 07, 2016 at 04:06:51PM -0400, George Kadianakis wrote: >In particular, onion addresses are currently composed of 16 random base32 >characters, and they look like this: > > 3g2upl4pq6kufc4m.onion > vwakviie2ienjx7t.onion >

[tor-dev] uProxy adds Tor support

https://blog.uproxy.org/2016/09/uproxy-adds-tor-support.html This blog post says that uProxy gained support for proxying others' traffic through Tor. uProxy client → censor → uProxy server → Tor → destination In the classic uProxy deployment scenario, the client and server are people who know

Re: [tor-dev] Tor Browser downloads and updates graphs

On Mon, Sep 12, 2016 at 11:12:15AM -0400, Mark Smith wrote: > On 9/11/16 3:45 PM, David Fifield wrote: > >> * We don't know what (8) or (9) is but it seems to us we are losing > >> users over time and are only getting them back slowly if at all. A > >> week

[tor-dev] Pluggable transport idea: TLS session resumption

Here's an idea for a new pluggable transport. It's just a TLS tunnel, but with a twist that allows the server's certificate to be omitted, depriving the censor of many classification features, such as whether the certificate is signed by a CA, the certificate's lifetime, and whether the commonName

Re: [tor-dev] HTTPS Everywhere

On Mon, Sep 05, 2016 at 10:28:26PM +0530, AKASH DAS wrote: > Can I know the issues that are currently in https everywhere. I don't know if this is what you're looking for, but here are some open bug tracker tickets.

Re: [tor-dev] Some information about Tor relays

On Fri, Aug 26, 2016 at 04:46:45AM +, Liu, Zhuotao wrote: > Thanks for that info, David. That seems valuable to me. :) > > However, I am a bit confused about the definition > > "cell-circuits-per-decile": Mean number of circuits that are included in any > of the deciles, > rounded up to

Re: [tor-dev] Some information about Tor relays

On Fri, Aug 26, 2016 at 01:42:38AM +, Liu, Zhuotao wrote: > This is Sky from University of Illinois. Currently we are working on research > project related with Tor. > > To help us to better design and evaluation our proposal, we need some > information about the Tor relays that is currently

[tor-dev] GreatFire Circumvention Central: tests of speed and stability of circumvention tools in China

https://en.greatfire.org/blog/2016/jul/greatfireorg-now-testing-vpn-speed-and-stability-china https://cc.greatfire.org/en "Our newest website, Circumvention Central (CC), aims to provide real-time information and data about circumvention solutions that work in China. Since

[tor-dev] meek-server performance improvements?

I saw you say on IRC that you had an idea for improving the efficiency of meek-server. What's your idea? The server hosting meek-azure is passing 90% CPU at times. One idea I've seen is using one connection for upstream data (data-carrying POSTs, emptry responses), and one connection for

Re: [tor-dev] Using Let's Encrypt for meek bridges

On Fri, Apr 08, 2016 at 05:28:45PM -0700, George Tankersley wrote: > > I'm looking for ideas of good ways to handle TLS certificates and their > > renewal for meek bridges. I want to use Let's Encrypt for this process, > > and I hope that someone who knows Let's Encrypt well can contribute some >

Re: [tor-dev] iObfs: obfs4proxy on iOS

On Mon, Apr 04, 2016 at 12:04:45AM -0400, Mike Tigas wrote: > [again, cross-posted to tor-dev and guardian-dev.] > > A quick status report on this: it works! Hit a big epiphany, figured out > how to get `gomobile` to emit the necessary bits, then went wild. > > Some example stdout from Onion

[tor-dev] Using Let's Encrypt for meek bridges

I'm looking for ideas of good ways to handle TLS certificates and their renewal for meek bridges. I want to use Let's Encrypt for this process, and I hope that someone who knows Let's Encrypt well can contribute some ideas. All three of the meek bridges use HTTPS to receive connections from the

Re: [tor-dev] Request for feedback/victims: cfc

During the OONI survey to find instances of server-side Tor blocking, we found a few variations on CloudFlare captcha pages. They don't all say "Attention Required!". Apparently there is an option to customize the page, but few sites make use of it. Here are the regexes we used (excerpted from

[tor-dev] Summary of meek's costs moved to tor-project list

I decided to move the meek cost emails to the tor-project list, because they are more project-y than dev-y. Here is the email for January 2016: https://lists.torproject.org/pipermail/tor-project/2016-February/000101.html There's a table of all previous summaries here:

Re: [tor-dev] Configuration of tor relay using setup files (use of API via Tor Expert Bundle)

On Sun, Feb 07, 2016 at 03:44:35PM +, Nathan Bliss wrote: > Is there a way to configure a bridge in tor (e.g. meek) via the config files > from the command line without having to use the GUI in the Tor browser? I've > been searching for documentation on this, so if I've missed it I would be >

Re: [tor-dev] Introducing Snowflake (webrtc pt)

On Mon, Jan 25, 2016 at 02:34:42PM -0800, Serene wrote: > Snowflake is a webrtc pluggable transport inspired by flashproxy. > (https://gitweb.torproject.org/pluggable-transports/snowflake.git) > Arlo, David, and I have made lots of progress on it lately, and it now > appears to have reached

Re: [tor-dev] Does Orbot use default obfs4 bridges?

On Tue, Jan 19, 2016 at 03:29:38PM -0500, Nathan Freitas wrote: > > On Tue, Jan 19, 2016, at 02:52 PM, David Fifield wrote: > > Does Orbot have a list of default built-in obfs4 bridges? Or do users > > fetch them dynamically? I looked in the source code and found defaul

[tor-dev] Does Orbot use default obfs4 bridges?

Does Orbot have a list of default built-in obfs4 bridges? Or do users fetch them dynamically? I looked in the source code and found default meek bridges but not default obfs4. I'm asking because we recently added a few new high-capacity default obfs4 bridges.

Re: [tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)

On Sun, Jan 17, 2016 at 10:24:47PM +, cacahuatl wrote: > On Sun, Jan 17, 2016 at 01:01:03PM +0100, coderman wrote: > > misguided because it won't work as you expect, the right way to check > > is to build circuits and see where they exit from. you can do this > > yourself! > > Tor Project

Re: [tor-dev] Questions about censorship detection paper

On Tue, Jan 12, 2016 at 11:49:19PM +, John wrote: > Hi David, > > Thank you, these pointers were very helpful. Do you know if there is > some kind of resource that lists known censorship events? I'd like to > see how good the approach from the paper does at identifying them. For Tor-specific

Re: [tor-dev] Summary of meek's costs, December 2015

On Mon, Jan 11, 2016 at 02:51:12PM -0900, Jesse V wrote: > On 01/11/2016 02:42 PM, David Fifield wrote: > > We still have support from > > Google, so that $561.29 actually costs about $61.29. > > Oh, I was not aware of this. When does the support expire, and how much >

Re: [tor-dev] Questions about censorship detection paper

On Tue, Jan 12, 2016 at 07:21:39AM +, John wrote: > I ran into the technical report from George Danezis about an > anomaly-based censorship-detection system for Tor. I have a few > questions that I hope you can help me with. > > Is there an implementation available of the approach described

[tor-dev] How many exits exit from an IP address different than their OR address? (10.7%)

I wanted to know how many exits exit from an address that is different from their OR address. The answer is about 10.7%, 109/1018 exits. The interesting part is that of those 109 mismatches, 87 have an exit address that differs from the OR address in all four octets; i.e., the IP addresses used by

Re: [tor-dev] Go version in Gitian descriptors

On Sun, Jan 03, 2016 at 11:01:25PM -0600, Jeremy Rand wrote: > I noticed that it looks like Tor Project is using Go 1.4.2 to build > the pluggable transports in Gitian. I'm curious why a newer version > of Go isn't used. My understanding is that Go 1.4.2 (or earlier) is > needed to build Go 1.5

Re: [tor-dev] Bitcoin-paid hidden meek relays?

so blocking them is not an option and having them behind TLS > makes it even more complicated. > > The problem I noticed though is that the costs of Meek go up and if I > read the reports from David Fifield (the maintainer of Meek), the > bandwidth has to be limited to avoid

Re: [tor-dev] Better relay uptime visualisation

On Mon, Dec 07, 2015 at 02:51:23PM -0500, Philipp Winter wrote: > I spent some time improving the existing relay uptime visualisation [0]. > Inspired by a research paper [1], the new algorithm uses single-linkage > clustering with Pearson's correlation coefficient as distance function. > The idea

Re: [tor-dev] Better relay uptime visualisation

On Tue, Dec 08, 2015 at 10:47:08AM +1100, Tim Wilson-Brown - teor wrote: > > On 8 Dec 2015, at 10:43, Tom Ritter <[1]t...@ritter.vg> wrote: > > On 7 December 2015 at 13:51, Philipp Winter <[2]p...@nymity.ch> wrote: > > I spent some time improving the existing relay uptime

Re: [tor-dev] Graphs - Estimated Traffic Capacity

On Fri, Nov 20, 2015 at 01:38:56PM -0500, David Goulet wrote: > Anyway, if you think this algorithm could be improved, please respond. If you > think this algorithm is wrong, please respond. If you can reproduce the result > on your own with this algo, omg please respond! :) The above could be

Re: [tor-dev] Summary of meek's costs, October 2015

On Fri, Nov 20, 2015 at 05:50:51PM -0600, Tom Ritter wrote: > On 18 November 2015 at 16:32, David Fifield <da...@bamsoftware.com> wrote: > > There was an unfortunate outage of meek-amazon (not the result of > > censorship, just operations failure). Between 30 September and 9 O

[tor-dev] Summary of meek's costs, October 2015

Here's the summary of meek's CDN fees for October 2015. App Engine + Amazon + Azure = total by month February 2014$0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014

  1   2   3   >