Re: [tor-dev] Relay "Ping" Functionality

Well onioncat is not "arbitrary node" but is a set up one. Yet some timing differentiations can be divined by selectively constructing the "circuit" to test, looking at setup timings, pushing characterizing traffic through them and your own nodes, polling existing services, etc. Please publish

Re: [tor-dev] Relay "Ping" Functionality

> Right now we're exploring latency-based attacks but are having trouble > achieving a particular goal: a way to “ping” an arbitrary node in a > client’s already-built (“live”) circuit. One-way timing is ideal but round > trip time would suffice. We can glean this information during circuit >

Re: [tor-dev] [tor-relays] Relays running an unsupported (EOL) Tor version

> mpan: >> Is there any data available that sheds light on >> why operators run outdated versions Besides latent OS packages, or being busy, or simply not updating things, those are natures of computing world anyway... or having no network operations crypto-monetization model as some nextgen p2p

[tor-dev] v2 Onions, IPv6 BiDir P2P Capability Regression... [re: Relays running unsupported EOL ver]

On that, and regardless of what TPO Inc says re... tor is a bit decentralized, and freely licensed, as such... DirAuths, HSDirs, Relays are all free to choose to continue signing over and running older versions in order to support the community of tor clients that are happily using useful

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

>> https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021 >> tpo/community/support/#40013 > > https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe > https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockingTor Beyond talk (and dev) there was

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

> https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/GSoC-2021 > tpo/community/support/#40013 https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockingTor The importance due to negative utility

Re: [tor-dev] Lets give every circuit its own exit IP?

signal NEWNYM exit bucketing - Make circuit isolation isolate exits? https://trac.torproject.org/projects/tor/ticket/6256 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] interested in working on a ticket

> https://trac.torproject.org/projects/tor/ticket/13184 . Perhaps not only "which local network", as in customary 127.0.0.0/8, but may be useful to some as being flexibly narrow to "which IP and port", as in 127.201.52.38:843, for IPv6 as well. Some OS / VM may utilize beyond concept of just

Re: [tor-dev] torsocks configure bug (uClibc, maybe other nonstandard libcs)

> libc.so.0 => ... > ld64-uClibc.so.0 => ... Samples from systems for developing pattern matches should not be truncated... if the data is sensitive or very long, it can be obfuscated or have its char class substrings shortened. Some forums and mail can mangle chars classes outside isalnum(3),

Re: [tor-dev] Compile warns

On 9/10/19, Nick Mathewson wrote: > https://trac.torproject.org/projects/tor/ticket/31687 > needs testing; please let me know if it works for you. Works. The second hunk for fp.c is below. > Is it possible that > a new compiler version or new headers in FreeBSD is what has made them > start

Re: [tor-dev] Compile warns

On 9/6/19, Nick Mathewson wrote: > What version of Tor? Oops, here it is: 0.4.1.5 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Compile warns

freebsd 12 x64 gcc 8.3.0 src/core/or/connection_edge.c:2563:5: warning: potential null pointer dereference [-Wnull-dereference] src/lib/math/fp.c:106:16: warning: conversion from 'double' to 'float' may change value [-Wfloat-conversion] src/lib/math/fp.c:111:18: warning: conversion from 'double'

Re: [tor-dev] Putting onion services behind a third-party TCP proxy

On 8/14/19, Pop Chunhapanya wrote: > When deploying an onion service ... the ip address > of my machine ... is exposed to the Tor network... > DDoS ... if someone knows my ip address. Only your tor client, and your guard, knows your ip. Unless you're up against a malicious guard, that's not a

[tor-dev] User Data Exchange with Network Automata (re: Prop 305, ex energy)

> And this is really off topic for this list. General Tor energy bits moved here... https://lists.torproject.org/pipermail/tor-talk/2019-June/045256.html re 305 etc It wouldn't be unusual for an app to pop up some form of captcha, challenge, or data exchange where needed. Some of that model

[tor-dev] Cryptocurrency: Total Energy Analysis - Crypto Uses Less Than Fiat

(from tor-dev: PoW DoS defenses Prop 305: INTRO Cell) On 6/16/19, Chelsea Holland Komlo wrote: > Given the significant environmental impact of POW in other distributed > systems (blockchain), we should not implement schemes that solve a > problem for Tor but create problems for people elsewhere

Re: [tor-dev] Proposal 304: Extending SOCKS5 Onion Service Error Codes

This should make sure these errors are synchronized with that from controller events HS_DESC HS_DESC_CONTENT HSFETCH HSPOST and other semantics and logging. I submitted a bunch of bugs and enhance on HS* controller command and event failures that can be trac searched and integrated with this. Some

[tor-dev] Solving World's Tor Users Being Blocked by Websites (was: Tor exit bridges)

On 5/7/19, nusenu wrote: > > juanjo: >> Tor relays are public and easily blocked by IP. To connect to Tor >> network users where Tor is censored have to use bridges and even PTs. >> But, what happens on the exit? Many websites block Tor IPs so using >> it to access "clearweb" is not possible.

[tor-dev] Controller: text connection vs SNMP

Speaking of MIBs and management, was SNMP ever seriously looked at back when desire for a control mechanism evolved? If I recall, agent libs and clients weren't wished as middleware, thus demurring to a text connection shell interface. Though commercial routers have both, the shell connection is

Re: [tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

On 5/7/19, Suphanat Chunhapanya wrote: > That's cool. But according to what dgoulet proposed, if we use both > ONION_CLIENT_AUTH_ADD > and ONION_SERVICE_AUTH_ADD. The latter will sound like it's an > authentication of the service not the client. At least for me :) And or maybe that seem more

Re: [tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

On namespaces... Like MIBs, APIs, file systems, most anything, it's usually... least specific left to most specific right ... DNS also maintains hier but in reverse direction. add_foo_thing1 add_thing1 add_thing2 see_bar_thing1 string_assorted_junk_this ... gives you hierarchies of *add*

Re: [tor-dev] Tor Directory Meta-Format + Line Wrapping?

On 4/3/19, Iain Learmonth wrote: >> When line wrapping, implementations MUST wrap lines >> at 64 characters. Upon decoding, implementations MUST >> ignore and discard all linefeed characters. The sectiion quoted is here... https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n193 > I

Re: [tor-dev] Tor Friendliness Scanner

On 3/4/19, Kevin Gallagher wrote: > Recently I've been > working on creating a "Tor Friendliness Scanner" (TFS), or a scanner > that will measure what features of a given website are broken > (non-functional) when accessed on the Tor Browser (TB), along with > actionable suggestions to improve

Re: [tor-dev] tor relay process health data for operators (controlport)

All sorts of statistical counters could be useful to graph from some API... a control port stats dump in something like var=value, a BSD sysctl text format, and even up to a proper SNMP port which many graphers already speak. Logging isn't really the right place for such things, unless they've

Re: [tor-dev] New Proposal: Preferring IPv4 or IPv6 based on IP Version Failure Count

> https://github.com/torproject/torspec/pull/53 > https://trac.torproject.org/projects/tor/ticket/27491 > https://github.com/torproject/tor/pull/566 > https://github.com/torproject/torspec/tree/master/proposals The subject would make use of the folllowing RFC... Happy Eyeballs Version 2: Better

Re: [tor-dev] HTTPS and Tor Onion v3 Services

> rewriting onion proxies Though it should be noted that if users already can't get their own simple human link and bookmark usage right... they're probably not going to get any higher level naming or authority config and usage right either. ___ tor-dev

Re: [tor-dev] HTTPS and Tor Onion v3 Services

> sign a > self-signed tls certificate with your Onion Service's hs_ed25519_secret_key > and Tor Browser trusting the tls certificate based on this signature - In unlikely case tor crypto fails or breaks, e2e TLS is good there. - An admin might terminate onions on one box, and forward the

Re: [tor-dev] Upcoming Tor change with application impact: "Dormant Mode"

Regarding mobile, dormant, battery, etc... There may still be a ticket for phone, mobile, laptop, wifi users... if an interface change happens, typically interface down event or IP change, then tor should tear down all internet associated state, to not expose traveling user to identifying IP

Re: [tor-dev] Tor Relay Guide Disagreements

> /TorRelayGuide > /TorRelayGuide/DebianUbuntu The former, in context wiith the latter, cannot be treated as both a file and a directory (hier) by web mirror / archvers such as wget onto disk. And wiki / trac exports aren't available either :( So instead push the page down into the hier, thus

Re: [tor-dev] Entreaty for spreading awareness about ProxAllium, a useful frontend for Tor

> I am not sure where I should start with getting feedback as it is quite hard > to find users of ProxAllium. People can't be forced to use or comment. Yet if it's a tool that interacts with tor or the ecosystem of tor tools, post up an announce and feedback request to tor-talk and see. When

Re: [tor-dev] Entreaty for spreading awareness about ProxAllium, a useful frontend for Tor

> https://proxallium.org/ > adding references to it in places like the wiki and the "projects" list on > the website. People are free to create their own wiki account and add descriptions and links to their tools / projects on the relavant wiki pages. https://trac.torproject.org/ You probably

Re: [tor-dev] Proposal: Check Maxmind GeoIP DB before distributing

Thanks for your work. You may also consider Africa and South America, Canada, Russia, etc. And locations interior to all such that contacts within an RTT are not as likely to be across a pond or other border, vs as at some edge IX or landing. Cable maps may assist.

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

On Sat, Jun 30, 2018 at 5:22 PM, nusenu wrote: > tor's man page for OutboundBindAddress* options say: > >> IPv6 addresses should be wrapped in square brackets > > since it does not throw an error without square brackets: > does it make any difference? > > Previously I forgot the square brackets

Re: [tor-dev] onion v2 deprecation plan?

> for v3 support, HSFETCH won't be ncessary... N... HSFETCH is an absolutely necessary control function now critical to operation of a variety of onionland search / index / status / webhosting / research services, and any other basic commandline checks that have zero wish to be spawning

Re: [tor-dev] onion v2 deprecation plan?

On Fri, Apr 27, 2018 at 8:01 AM, Alec Muffett wrote: > OnionBalance Forgot to include this in the former list of common / useful onion tools, thanks. If anyone knows of others, feel free to add to thread. > OTOH, I have been performance testing simultaneous

Re: [tor-dev] onion v2 deprecation plan?

On Wed, Apr 25, 2018 at 2:22 PM, nusenu wrote: > even though you are probably years away from deprecating onion v2 services > it is certainly good to have a clear plan. > > I'm asking because the sooner onion v2 are deprecated the sooner some > people can stop worrying

Re: [tor-dev] Lets give every circuit its own exit IP?

You may also be interested in - newnym exit bucketing (in trac somewhere), this guarantees cycling through all exits before reusing one - openvpn exit termination (in tor-relays somewhere), this gives non-tor IP to clients that initiate a termination ___

Re: [tor-dev] Is OutboundBindAddress respected during ORPort IP auto detection?

It seems that each function in a network app that - listens to the net, should have an independantly configurable inbound ip and port. - talks out to the net, should have an independantly configurable source ip and port. And when there are multiple interfaces / NAT, address metadata and metainfo

Re: [tor-dev] Setting NumEntryGuards=2

On Thu, Mar 22, 2018 at 1:13 PM, Mike Perry wrote: > I strongly disagree. Dumping more traffic onto an already existing, > otherwise in-use connection is not the same as the ability to force a > new connection that is only used for a single request at a very specific >

Re: [tor-dev] 3.2.10 compiler warnings

On Fri, Mar 9, 2018 at 11:20 PM, teor wrote: > Can you tell us what compiler and version, and what system? Was gcc 4.2.1 modded by whatever freebsd did in its 8.x series. Any extant bugs... ok, but don't bother porting for those releases as they're EOL / moot.

[tor-dev] 3.2.10 compiler warnings

Test from an older system before it was updated, unlikely to be prevalent, so don't bother fixing unless obvious. src/common/confline.c:135: warning: 'include_list' may be used uninitialized in this function src/common/confline.c:135: warning: 'include_list' may be used uninitialized in this

Re: [tor-dev] Creating custom Tor Browser settings profile

On Mon, Feb 26, 2018 at 12:26 AM, procmem wrote: > Any way to do this? See 'firefox -h'. Then see if 'torbrowser -h' and args work the same way. ___ tor-dev mailing list tor-dev@lists.torproject.org

Re: [tor-dev] Agnostic Tools: Code Dev and Support For

On Thu, Jan 11, 2018 at 5:44 PM, teor wrote: > This thread is off-topic > This list is used for developing new features, bug fixes, and > removing old features. Here are three easily found and directly quoted charters for this list, none of which are strictly constrained to

[tor-dev] Agnostic Tools: Code Dev and Support For

> I'm interested in helping you guys with Tor development. I don't really care > what I work on, except I do not support .onion websites (though I am willing > to be convinced otherwise) so I would prefer not to participate directly in > their development. I have plenty of experience with writing

Re: [tor-dev] Relay diversity master thesis

On Sun, Jan 7, 2018 at 8:29 AM, teor wrote: >> On 22 Dec 2017, at 11:23, Robin Descamps wrote: >> May I ask you advices/feedback about this master thesis plan? >> The master thesis plan: >>

Re: [tor-dev] Rust rewrite help

> Recently, I spent some time in China > and it made me realize the importance of a project like TOR. Consider speaking of your experience on the cypherpunks and/or liberation-tech lists, anonymously if need be. Your contribution is valued. ___ tor-dev

Re: [tor-dev] #tor-dev exitmap

On Sat, Dec 23, 2017 at 12:49 AM, Harshavardhan Reddy wrote: > How does the Tor Project deal with the malicious exit relays. Do you still > run exitmap or something better? As with dirauths, the effort is distributed and not necessarily a function of the tor project

Re: [tor-dev] Detecting multi-homed exit relays (was: Onion auto-redirects using Alt-Svc HTTP header)

>> Detecting exit nodes is error prone, as you point out. Some exit nodes >> have their traffic exit a different address than their listening >> port. Hey does Exonerator handle these? > > Right. It's not trivial for tor to figure out what exit relays are > multi-homed -- at least not without

Re: [tor-dev] Question on Tor Design (current and maybe past and future)

> https://www.torproject.org/docs/documentation.html.en#DesignDoc > https://spec.torproject.org/ > https://gitweb.torproject.org/torspec.git/tree/ > https://gitweb.torproject.org/torspec.git/tree/proposals > https://trac.torproject.org/projects/tor/report/12 >

Re: [tor-dev] anonbib

On Mon, Nov 6, 2017 at 12:56 AM, ng0 wrote: > I think videos should be a separate issue, we selfhost them > already as far as I know but integrating them into git is > no (good) solution. Don't think I would propose committing the actual videos / papers to git... too much

Re: [tor-dev] anonbib

On Sat, Nov 4, 2017 at 8:05 PM, Scfith Riseup wrote: > I wonder if there is an option to start to use ipfs ( https://ipfs.io/ ) or > something like it to permanently and resiliently store items for posterity? Bib users would need a client to avoid abusing inproxy. Though a

Re: [tor-dev] anonbib

> With mentioned problems of - Broken links, not founds, redirects covered by a single monthly crawl thus being regular and benefitting all projects at once. - Size, could apply common compression such as xz or even ZSTD to entire mirrorable local archive. Similar for video materials.

Re: [tor-dev] anonbib

> Saves a lot of duplicative work at the projects, is easily mirrored, > imported into web pages, etc. With mentioned problems of - Google threat covered by community hosting and replication. - Separate / overlapping project / topic focus covered by a flexible tagging and views system. - Not

Re: [tor-dev] anonbib

At some time in the past I noticed that the anonbib did not have links to local copies of some of the materials. If that's still the case, I'd definitely suggest creating them at this oppurtunity. And though rare and more curation work, some papers do receive content / errata updates.

Re: [tor-dev] (no subject)

On Sun, May 14, 2017 at 9:35 AM, harshit tandon wrote: > I would like to contribute to tor browser how can I help Start by filling out the "^Subject: ' lines of your emails with a relavant "Subject" so people know what you're talking about instead of leaving them

[tor-dev] Tracing TCP Connections online..

re: "tcp_tracing_internet.pdf" This appears to describe an active network modulation attack (node DoS). Either hammer tree on nodes of the expected path and trace the modulation, or on all but the expected path to find unmodulated. It generally requires GPA, deploying nodes, or being one end of

[tor-dev] Reverse Naming Proposals?

These recent naming proposals on list, for forward naming 'string --> onion, 1:1', I think. Is anyone working on doing reverse naming, 'onion --> string, 1:1' ? With links to such work? ___ tor-dev mailing list tor-dev@lists.torproject.org

[tor-dev] Circuit times

Anything going to blow up if set anywhere from 1k to 1M? CBT_NCIRCUITS_TO_OBSERVE ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Mailing List Etiquette Reminder

New members are very welcome and valued whether through gradual accretion or project influx such as GSOC's. In order to ensure messaging efficiency and clarity... - Reply *below* what others have written. Do not "top post". - Trim out and *delete* irrelavant portions of what others have written,

Re: [tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

On Tue, Mar 28, 2017 at 11:31 AM, Donncha O'Cearbhaill wrote: > The Tor bad-relay team regularly detects malicious exit relays which are > actively manipulating Tor traffic. These attackers appear financial > motivated and have primarily been observed modifying Bitcoin and

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

On Wed, Mar 29, 2017 at 3:38 PM, Felipe Dau wrote: > Thanks for the suggestion. It should be possible to support multiple > kinds of transport, but we still need to do some research on that > because it might make some attacks > possible/easier (e.g., partitioning attacks)? It

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

You may want to link unmessage into the I2P network as well. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Netflow padding

Are these the current / recommended paper refs for eyeballing things on this to date? torspec/proposals/251-netflow-padding.txt torspec/proposals/254-padding-negotiation.txt ___ tor-dev mailing list tor-dev@lists.torproject.org

[tor-dev] Prop224 oppurtunity: keygen, crypt, sign, encoding tools

Tor could ship with a tool to offline generate all the various keys, encrypt and sign with them, for debug, test, and use with other apps that tie to tor. And a tool to translate strings between different encodings in use. Or at least provide howto and links in the docs to third party tools that

Re: [tor-dev] git-update: transparently torified git pulls

> test x"$url" = x Some users may be a bit unfamiliar with this longform 'test' construct having trended from that in say their distro's example rc scripts over recent posix and bugfixed decades, easier visual delimited parsing, 4 chars of line width saved, to form of... [ ! "$var" ]

Re: [tor-dev] tor 0.2.9.9 gcc 4.2.1

It was a test compile on a very old 8.x i386 box, warnings would be no surprise there, hardly worth addressing unless exposed a bug, since 11.x runs on most all hw 8.x does. gcc version 4.2.1 20070831 patched [FreeBSD] ___ tor-dev mailing list

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

Skimming thread... Version or not is fine, provided if you want versions you know you must store the bits somewhere, or ensure regex parser rules to recognize and match an intrinsic version represented by entire address format specification itself. Note onion search spiders rely on such address

[tor-dev] tor 0.2.9.9 gcc 4.2.1

Ancient gcc says src/or/connection.c:1843: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/or/connection.c:1843: warning: passing argument 1 of 'TO_OR_CONN' discards qualifiers from pointer target type src/test/test_dir.c:3700: warning: assuming signed

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

On Wed, Jan 18, 2017 at 3:31 AM, George Kadianakis wrote: > What do you mean by "develop an IPv6 layer"? prop224 destroys the one to one bidirectional binary mapping that makes onioncat possible, and fails to provide a replacement for it :-( Any "human naming" layer

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

Always wondered how naming is relevant, for example, IPv6 with OnionCat as a deterministic form of naming. So now we propose a 'naming' layer. Which should not also support IPv6 addressing? Is not IPv6, subsequent to the 80bit scheme, merely a name on top of onions? ie: If we develop a 'naming'

Re: [tor-dev] RFC: Tor long-term support policy

You may encounter special justification to extend support for last branch that still supports pre-prop224 onions. There is a *lot* of code / community built on those. Darknet fora have mentioned possible maintenance forks as such if need be. ___ tor-dev

Re: [tor-dev] Request for comments: patch to mark exit traffic for routing and statistical analysis

> On 2016-09-26 00:54, teor wrote: >> The one concern I have about this is that Tor-over-Tor would stick out more, >> as it would look like Tor coming out the OutboundBindAddressExit IP. >> But we don't encourage Tor-over-Tor anyway. ToT is technically not some special tor aware / tunneled relay

Re: [tor-dev] Onioncat and Prop224

On Thu, Jun 23, 2016 at 3:51 PM, grarpamp <grarp...@gmail.com> wrote: > Freenet has talk on their lists of adding 100 new onioncat nodes > to tor and i2p as linked to in this thread... > > https://lists.torproject.org/pipermail/tor-dev/2016-June/011108.html More folk

Re: [tor-dev] Proposal 273: Exit relay pinning for web services

On Wed, Oct 5, 2016 at 4:09 PM, Philipp Winter wrote: > Also, Tor Browser MUST abort the ERP procedure if the HTTPS > certificate is not signed by a trusted authority. This is a problem for independant sites that choose not to pay the CA cabal, deal with what free CA will be

Re: [tor-dev] Onioncat and Prop224

Many wrote, in subthread started by dawuud 5 days ago: > talk: internet of things, security / exploit / nsa, crypto via tor, > everything over tor, exits This subthread does not concern the subject made for curating / supporting / tracking / developing "Onioncat and Prop224" [1]. Please a) end

Re: [tor-dev] Onioncat and Prop224

On Wed, Sep 28, 2016 at 11:30 AM, dawuud wrote: > Are you aware of Tahoe-LAFS? Don't know if they are, or if they are here, all we have is their short post. If they just need an insert and retrieve filestore for small user bases, there are lots of choices. If they need the

Re: [tor-dev] Onioncat and Prop224

https://www.reddit.com/r/TOR/comments/54rpil/dht_syncthing_bitsync_over_tor/ Hi we would like to integrate DHT Bittorrent Syncing over Tor for our open source encrypted obfuscated media rich notepad app. This app will have for main objective to provide a secure information gathering and sharing

Re: [tor-dev] More tor browser sandboxing fun.

There is VM's, and Multiple X server can isolate on up to all available vty's. There is also program shipped by X11 called Xnest. But the more concern than apps and keyboards above, is probably the driver / kernel portion of security surface. ___ tor-dev

Re: [tor-dev] More tor browser sandboxing fun.

On Wed, Sep 21, 2016 at 5:33 AM, Yawning Angel wrote: > Where: https://git.schwanenlied.me/yawning/sandboxed-tor-browser > X11 is a huge mess of utter fail. Since the sandboxed processes get direct > access to the host X server, this is an exploitation vector. Is

Re: [tor-dev] Potential regression when binding sockets to interface without default route

On Mon, Sep 19, 2016 at 5:36 PM, René Mayrhofer wrote: > That is exactly what we have patched our local Tor node to do, although > with a different (slightly hacky, so the patch will be an RFC type) > approach by marking real exit traffic with a ToS flag to leave the > decision

Re: [tor-dev] Potential regression when binding sockets to interface without default route

On Mon, Sep 19, 2016 at 9:14 AM, René Mayrhofer wrote: > Sep 19 11:37:41.000 [warn] I have no descriptor for the router named > "ins1" in my declared family; I'll use the nickname as is, but this may > confuse clients. > Sep 19 11:37:41.000 [warn] I have no descriptor for the

Re: [tor-dev] Please consider allowing /48 for VirtualAddrNetworkIPv6

On Fri, Sep 16, 2016 at 6:10 PM, Alex Elsayed wrote: >> (Yes, there is a typo in the last IPv6 address as well. >> https://trac.torproject.org/projects/tor/ticket/20153 ) Yes Tor is making some quite bad text representation issues so I added summary of them to this ticket.

Re: [tor-dev] Please consider allowing /48 for VirtualAddrNetworkIPv6

On Fri, Sep 16, 2016 at 5:13 AM, Alex Elsayed wrote: > Hi, I'm using Tor in transparent mode, and I'm running into a rather > inconvenient behavior. > > VirtualAddrNetworkIPv6 refuses to parse unless the network address given > is a /40 or broader. However, IPv6 ULA, which

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

> On Fri, Aug 26, 2016 at 01:42:38AM +, Liu, Zhuotao wrote: >> We hope to have an estimate about computation capacity of Tor relays. For >> instance, how many circuits a relay can maintain when its CPU is driven to >> about 100%? On average, how many circuits are maintained by a busy guard >>

Re: [tor-dev] Alternative Implementations of Tor

Add your projects here... https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] prop224: zero bits in addresses

And 10 years down when 20 bits is easy, you're going want shrinking it again, or along any interim update cycle. This is going to upset downstream parsers such as web indexers that expect matching fixed length / pattern. or that have to write zero [de]fillers. ex: [a-z2-7]{16}\.onion, we now see

Re: [tor-dev] Onioncat and Prop224

Hi Jeremy. In regard your post 'Tor and Namecoin' here... https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html In this thread prefixed 'Onioncat and Prop224' started and spanning from here through now... https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html

Re: [tor-dev] Using Tor Stealth HS with a home automation server

> Nathan Freitas writes: >> Any thoughts on a format? torhs://clientname:authcookie@foo.onion looks >> decent. You probably want to coordinate with ricochet if it doesn't already have such QR sharing feature. ___ tor-dev mailing

[tor-dev] Torsocks workalikes

I remember a survey list of torsocks workalikes somewhere (where?). This one's for windows and I don't remember it. Whoever maintains that list can add it for reference. https://github.com/cpatulea/TorCap2 ___ tor-dev mailing list

Re: [tor-dev] Onioncat and Prop224

Freenet has talk on their lists of adding 100 new onioncat nodes to tor and i2p as linked to in this thread... https://lists.torproject.org/pipermail/tor-dev/2016-June/011108.html Is anyone working on resurrecting the onioncat mailing list and archives?

Re: [tor-dev] Freenet + Onioncat: Is the traffic welcome?

On 6/22/16, konst...@mail2tor.com wrote: > I want to be clear about a couple of things. I am not looking to defy the > wishes of Tor developers and relay contributors. I hope to get their views > on the matter. Should they explicitly refuse, I will look at I2P. When I ran,

Re: [tor-dev] Onioncat and Prop224

On 4/30/16, str4d <st...@i2pmail.org> wrote: > On 27/04/16 22:31, grarpamp wrote: >> Yep :) And I know Bernhard was hoping to get in touch with Roger >> on this before long. >> >> Basically, prop224 HS being wider than 80 bits will break onioncat's >>

Re: [tor-dev] [::]/8 is marked as private network, why?

On 3/29/16, Tim Wilson-Brown - teor wrote: > /** Private networks. This list is used in two places, once to expand the > So I think we should keep [::]/8 in the list of private addresses. > That said, the list of IPv4 and IPv6 private addresses in tor is incomplete, >

[tor-dev] Is it possible to leak huge load of data over onions?

On 4/3/16, Griffin Boyce wrote: > How do you transmit an elephant? One byte at a time... > > But on a serious note, it's possible to transfer 2.6TB over Tor in small > pieces (such as file by file or via torrent). Given the size, however, I'd > suspect they mailed hard

Re: [tor-dev] Much-revised draft, RFC: removing current obsolete clients from the network

The list of server/client -versions seems long and unuseful... 0.2.4.23 0.2.4.24 0.2.4.25 0.2.4.26 0.2.4.27 0.2.5.8-rc 0.2.5.9-rc 0.2.5.10 0.2.5.11 0.2.5.12 0.2.6.5-rc 0.2.6.6 0.2.6.7 0.2.6.8 0.2.6.9 0.2.6.10 0.2.7.1-alpha 0.2.7.2-alpha 0.2.7.3-rc 0.2.7.4-rc 0.2.7.5 0.2.7.6 0.2.8.1-alpha I'd cut

Re: [tor-dev] [GSoC '16] Exitmap project - Introduction and request for comments

On 3/18/16, Mridul Malpotra wrote: > b. For testing active attacks, can there be modules developed > keeping other cleartext protocols like SNMP and Telnet in mind? Tor only supports TCP of course, however any cleartext application protocol using it is subject

[tor-dev] Stopping the censoring of tor users (via exit bridges / proxies / OpenVPNs)

On 2/25/16, blacklight . wrote: > hello there! i don't know if this mailing list works but i thought of > giving it a try. > > i was lately reading an article ( >

Re: [tor-dev] Is it possible to specify voluntary delays in my Tor client?

On Tue, Jan 19, 2016 at 3:03 AM, Virgil Griffith wrote: > I.e., if I want the extra resistance to traffic analysis that higher latency > connections provide, is there a way to specify that in my Tor config? Higher latency, in and of itself, does not provide any resistance to

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

On Tue, Jan 12, 2016 at 9:58 AM, coderman wrote: > this is the proper situation. only question is who would have a > compelling use for separating outbound OR connections and outbound > Exit traffic, as per #17975? Bandwidth peering contracts preferential to push or eyeball

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

On Wed, Jan 13, 2016 at 4:27 AM, coderman wrote: >>> ... only question is who would have a >>> compelling use for separating outbound OR connections and outbound >>> Exit traffic, as per #17975? >> >> Bandwidth peering contracts preferential to push or eyeball traffic. >

Re: [tor-dev] Tor Control Protocol: multiple commands in a single line possible?

Parsing and escaping things on one line is often a pain. Atomic batching might be useful, though I've no use case. < BATCH BEG label < cmd1 < cmdN < BATCH END label < BATCH PRINT / DELETE label < BATCH EXEC label [instance] > BATCH RESULT label [instance] < BATCH RESULT AUTODEL params [label]

  1   2   3   >