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

[grarpamp]

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 your results.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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
> construction, but what about a “live” circuit? Ideally, this would be a
> periodic thing Tor already keeps track of, but as an on-demand or as a
> byproduct/side-effect of a different function would also work. We have not
> been able to find a way to do this within the Tor (sub)protocol specs or
> the control port spec.

Use OnionCat and ping6, it is exactly what you want.

https://www.onioncat.org/

Such "timing" attacks are in the scope of "Tor Stinks  -- NSA"
document. Users should become familiar with them, and that
slide deck, and other attacks from over a decade ago.
And with how tor does not address them.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 overlay-exit networks are now working with...
there can be other reasons people may run different versions...

tor the software is different from from Tor Project Inc.
The software is opensource and BSD licensed. Thus anyone
may copy, run, share, redistribute, fork, modify, support it,
create and vote in any consensus, run relays, run more
networks than just tor on their nodes, run services, etc,
completely without involvement from, and indeed in full
disregard of whatever Tor Project Inc and its people may say.
The tor protocol, code, and operational network are not
the property of Tor Project Inc, nor are its operators
and users under its command and control.
tor's users may run whichever of the many tor client implementations
they wish to run, and may run whatever protocols, applications, and
uses over the tor network that they wish.
tor's relay operators and dirauths are free to run and support
the running of older, different, forked, or project protocol addition
enhancement or migration versions, in part in order to support features
that some of the entire global userbase of tor are using, and have
no good replacement for, or may wish to develop apps to, and run
them upon or over, such features and capabilities in the future.

Such as the censored topic of v2 onions with OnionCat,
OnionVPN, etc in order to continue or design, deploy, and
run new p2p apps comms, etc over those, ie...

https://www.onioncat.org/

So a large number of relays may be freely and rightly choosing,
as is their right if they wish, to continue running a v2 onion version
for that.

And overlay nets have some great uses, some examples
of which Tor Project advertises, such that those users or
even operators may prefer not to post, so you may want to
consider some of those good uses for them in their stead,
even ones that are dependent on such versions.

And another topical fact re versions, which will be censored, is
that attackers do falsify their version strings, and a lot more, in
order to run whatever custom exploits they want against the network.
And that Traffic Analysis and Sybil attacks nodes are real and in use.
And that there is no longer sufficient warning and ongoing visibly
posted education on these and other matters, in particular
at point of download, install, splashpage, and frontpage...
even some warnings were removed... versioned away.
These are the sort of lack of info that can put users at severe risk.
Tor Project Inc is censoring embarassing or simple facts / info.
And is now attempting to silence and kill useful and in use features
and future application possibilities based on them, whitewashing
them with handwavy vague absolutist claims such as "old" or
"insecure", instead of creating detailed comparisons for users.
tor's users and operators are the ones who get to choose their own
versions, and use appropriate features / freedom / security tradeoffs,
not by the sole dictate of Tor Project Inc.
Which by the way is funded to $Millions per year so that is not
an argument to killing otherwise modularizable features either,
but may be why there are insufficient disclaimers, and censors.

On 10/28/21, Georg Koppen  wrote:
> I don't think we have [...] feedback

Well when Tor's hypocrites, liars, and frauds are censoring feedback
etc off all their "bricked up" fora, full stop. Thus their users and operators
are missing information and topical discussions may hardly flourish
can they in an environment of censor, chilled, and steered speech.
The censorship of conversation on tor by Tor Project Inc and its people...
while publicizing claims to cherish and uphold Free Speech ideals...
is blatantly hypocritical, and it must end.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 features that the Tor Project on
its high horse demands with its blanket fiat fist and refusing to consider
and support users... to remove from such users, herein as noted before,
v2 onions and simple OnionCat IPv6 /48+80 UDP transport P2P E2E
BiDir addressing and thus all current IPv6 capable apps incl VOIP Bittorrent
comms status chat game coins etc and future apps that needing such
tech to operate across onionland. That's bad, and a big regression in
service, both active now, and preventing potential development on
interesting new uses and applications in the future.

These users, these features, apps, and their recognized tradeoffs, their
free choices made therein, are of merit and import. And Tor Project
is choosing to censor and ban v2 and them without regard.

Perhaps some v2 users will likewise email all the relays
seeking not their censorship, but instead their support.
But perhaps due to any needs they may have to remain
unknown they may not be able to voice out to lists etc,
as such the surfaceweb cannot make dis-use assumptions
and must indeed hold v2 in their stead for them.

Kudos to those distributed DirAuths, HSDirs, and Relays who
refuse to comply with Tor Project Inc demands to crush all
v2 onion users and their legitimate use cases.

The better path is for TPO to either recognize and continue, or to
modularize v2 onion support out to community stewardship such
that the features that it provides may continue until a future vN
or a seamless scalable externally attached solution for the same
features and uses is found. And to make v3 the default choice
"advertised" in docs and configs, with v2 a lesser noted option
yet for just providing above capabilities.

Tor Project still doesn't have a version feature matrix table, nor
an honest open balanced and free to all authors wiki education
page detailing use case and tradeoff notes for users about
the v2+OnionCat vs v3 tech capabilities, thereby allowing tor
users to freely make educated choices therein on their own.
Instead it has a bricked up and censored prop blog and lists.
Like TPO's censorship, that's unfair, unwarranted, questionable,
and needs to end.

ps: Yes, upgrade, if merely behind on versions sake, lots
of good fixes, improvements, performance, features, security,
etc come with those.

But when it comes to a big and permanent regression of
overall network capability issue such as this, that's different,
and needs consideration beyond the vague handwavy
universal whitewash "reason" being uttered by TPO such as
"v2 insecure"... which is false re educated tradeoffs and uses
that users are free to evaluate and choose on their own.
In fact, users are in better more intelligent aware position
having learned a bit of something and made that themselves.

Users are also free to eval by bring forward to today sense
of the NSA's 10+ year old slides that noted "Tor Stinks".
What conditions, designs, capabilities, etc have changed
since then.


Cheers all.



On 10/5/21, Georg Koppen  wrote:
> Relays running unsupported Tor versions is a problem we have never
> really dealt with in a systematic way in the way. Some of you might
> recall that we (with the help of volunteers) tried back in 2019/2020 to
> get operators, running an unsupported Tor version, to upgrade[1] but
> then we dropped the ball. Alas.
>
> We just started that process again by contacting every relay operator
> running an outdated Tor version (any version not 0.3.5.x or 0.4.5.x or
> 0.4.6.x or 0.4.7.x) by email where possible. Additionally, we created a
> wiki page outlining the current process and things we still need to
> figure out.[2] On that page we plan to make statistics related to the
> EOL relay removal available as well, including the final list of relays
> we'll reject. Thus, stay tuned. Feedback, as always, is very much welcome!
>
> We plan to keep this topic on our radar this time while refining the
> process as we go. Meanwhile, if you are running a relay with an
> unsupported Tor version, please upgrade for the sake of our users' safety.
>
> If you need help, join us on #tor-relays or #tor-relays:matrix.org if
> you use Element.
>
> [1] https://blog.torproject.org/removing-end-life-relays-network
> [2] 
> https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-policy
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

>> 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 tor-access, though it
seemed more on tokenizing/tracking out permissive rights
granting structures only upon tor/vpn users, rather than the
services side investing into some DBM suggested methods
whereby both clearnet and tor/vpn users would have and
enjoy same class of equal rights and usage models, or on
developing/promulgating a rights based concept to the world.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 and freedom impact this big blocking
problem has been having on Tor users. The DBM project in the original wiki'd
links could/should have been first picked up and added adjunct to with the
publicly sphere engaged and reporting in the OONI style (itself started after
the decade of the DBM project started its outline). And the problem grew larger.

Cloudflare (TLS stripping spies), reCaptcha, etc... have only spread worse over
time now blocking even more percent of sites, by their default config and or by
negative biased wording in the blocking softwares config docs about tor users
that their customers then read and make bad misconcept about tor and its users
thus leading to more blocking being configured, meanwhile tor users have grown
in mass numbers, thus more negative impact total to bigger percent of people
using internet especially via tor and VPN.

At least some people formally looks at problem now, even if only first
GSOC, to proof and expose it to sunshine more, towards ending it.
Most of the project aspects for it are in searchable lists history around the
above links, including automating the scans, ranking, reporting, doing public
engagement against the blocks using the provided list of potential solutions
to get the problem solved, etc.

It is really very bad when Tor users are censored forbidden prevented from
right of just clicking and only *reading* information on the internet, let
alone Tor users needs to publish their own there, to reply interact
utilize with others in the fora and platforms and services, to use buy pay
support patronize and get delivery, to debate social meet discover help learn
politic etc, the right to *write* to the internet... under such discriminatory
predjudiced anti human right of participation, under these kneejerk
least-co$t-and-thought-given blocking regimes and mentalities.

The use of tor, VPN's, new overlay and proxy networks, to browse/use
the internet is only growing worldwide, for good ways and defensive protective
sensible reasons... but users still getting more "you are denied to use this
service via tor/VPN, your account has been locked and deleted, your datas
and balance has been confiscated, you are banned for life, you must submit
selfies phones IDs and all life data infos, etc" ... all just for using the
tor/VPN/proxy.

Such source based blocking methods even being applied to users
of IRC, and now to the cryptocurrency networks.

End these blocking regimes being deployed against freedoms
of millions of worlds users... "DontBlockMe"... indeed!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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

[grarpamp]

> 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 127.0.0.1 and ::1.

The special registries should probably be noted
in the manpage / examples...
https://www.iana.org/numbers
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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),
tab, space, newlines, control, wrapping, etc... in which case some
safer encoding or file transmission may be useful...

ldd | openssl base64 -e


> grep 'libc\.'
>
> to
>
> grep '\slibc\.'

1) Grep's conformant to at least this standard
do not support '\s' regarding whitespace...

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html

Nor do all systems comply to any particular least common standard,
or have their man pages current with the code itself...

https://www.freebsd.org/cgi/man.cgi
https://www.kernel.org/doc/man-pages/

regex, wctype, grep, sed, awk, tr, etc...


Perhaps try...

ldd /usr/bin/yes | sed -r 's,^[[:space:]]+,,' | awk '/^libc\./ {print $1}'


2) configure.ac:119:dnl Get libc full system path. ...

The function returns only the basename, not the full path,
so 119 should say something else.


3) The function may not have a case for the OP's system,
and assumes the input and text processing pipestream
is and acts the same between Linux* and FreeBSD* systems.
That gap and assumption should be checked.


4) The "default" shipped with latest FreeBSD release (12.x)
is libc.so.7 not libc.so.6 which would then also fail if the
parsing fails.


5) FreeBSD 12.x

ldd /usr/bin/yes | openssl base64 -e
L3Vzci9iaW4veWVzOgoJbGliYy5zby43ID0+IC9saWIvbGliYy5zby43ICgweDgw
MDI0OTAwMCkK
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Compile warns

[grarpamp]

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

Possible, depending on date, gaps in reporting, etc...
FreeBSD switched its base from gcc 4.2+ to llvm 3.3 in FreeBSD 10 (2014q1).
https://svnweb.freebsd.org/base/stable/12/contrib/gcc/?view=log
https://svnweb.freebsd.org/base/stable/12/contrib/llvm/?view=log
Users can choose among some compiler toolchain major revs from ports,
users default choice of "llvm" / "gcc" has dates in here...
https://svnweb.freebsd.org/ports/head/Mk/bsd.default-versions.mk?view=log

FreeBSD 12.x default is at llvm 8.0.1, which doesn't complain.

> do you see these warnings if you go
> back and build 0.4.0 or 0.3.5?

Yes to both.



--- tor-0.4.1.5/src/lib/math/fp.c.orig  2019-06-10 08:46:16.0 -0400
+++ tor-0.4.1.5/src/lib/math/fp.c
@@ -123,7 +123,7 @@
 tor_isinf(double x)
 {
   /* Same as above, work around the "double promotion" warnings */
-#if defined(MINGW_ANY) && GCC_VERSION >= 409
+#if (defined(MINGW_ANY)||defined(__FreeBSD__)) && GCC_VERSION >= 409
 #define PROBLEMATIC_FLOAT_CONVERSION_WARNING
 DISABLE_GCC_WARNING(float-conversion)
 #endif /* defined(MINGW_ANY) && GCC_VERSION >= 409 */

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Compile warns

[grarpamp]

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

[grarpamp]

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' to 'float'
may change value [-Wfloat-conversion]
src/lib/math/fp.c:136:16: warning: conversion from 'double' to 'float'
may change value [-Wfloat-conversion]
src/lib/math/fp.c:88:13: warning: conversion from 'double' to 'float'
may change value [-Wfloat-conversion]
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 problem, and if you are, firewalling doesn't
help anything there because you can't prevent
a real "DDoS" or any other modulation from
partitioning or otherwise giving away your onion.
Tor cannot defend against that class of attack.

Note that in a proper "onion only" configuration,
a box should have no inbound ports open.

There is something confusing with your wording.

If these replies don't help, please rephrase your question.

And or sanitize and post your torrc config and
invocation commandline.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 exists in form of onion service authentication
config... some helper data that grants access, makes things happen,
whether passive or active interrupt. The controller would be the interface.
Yet tor currently has no mechanism on platforms to handle such
protocols and popups... thus like onion auth, the user has know
they need it for something and configure it in advance.

Try investigating an ssh-agent like tor tool... preloaded
with users Proof-of-*, 2FA, consumables, etc to dole out,
even automatically, where needed and permitted.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

(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 (potentially
> irreversible environmental damage).
>
> https://www.theguardian.com/technology/2018/nov/05/energy-cost-of-mining-bitcoin-more-than-twice-that-of-copper-or-gold

One must first understand and enumerate the *entirety of all global energy
inputs* going into and making up the legacy fiat currency banking systems,
from both Government and Corporate sectors, and its results, before
attempting to make any claims that cryptocurrency is "worse" [1].
Such cataloging and analysis requires more work, more data, more actual
redpill thought, than just simple hashrate/J/$... so of course people take
shortcuts in such articles, as do other people in their pronouncements
stemming from them.

> Other less-destructive schemes exist to prevent DoS attacks. POW is a
> method, not a goal in itself. Taking a step back and examining the full
> spectrum of available tools would be better.

The needs and model for overlay nets, ie tor, will of course be
different than those above.
And always interesting where tech various ends up being applied.

[1] Hint: Cryptocurrency actually consumes less, and further finally forces
inefficiency and other undesired things out of Fiat by displacing it...
hopefully faster than it can adapt. Some say that has a value, one that
many will be quite happy to sink a bit of premium into if need be.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 may have been prematurely closed.
There have also been past talk about SOCKS5 on the list
related to returning of some more errors codes via SOCKS5.


Update also
https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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. Should we allow and start
>> using "exit bridges"? In I2P we have not this problem since there is
>> no central IP list of relays.
>
> there is no need to extend to one more hope to achieve this
>
> https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html
>
> https://lists.torproject.org/pipermail/tor-relays/2019-May/017273.html

It's possible to augment such outbound
solution offerings even further by running
an OpenVPN termination service so users
can transport UDP between clearnet as well.
VPNGate.net project has an idea there too.
Even large regional IPv6 pools could be bought
and shared by operators and rotated through.

More tor relay operators should consider
some of the above options, whether as a
requested "bridge" service mechanism, or
listed in the consensus "contact" field, or
as more of a standalone VPNGate support,
or "ExitGate" project sort of arrangement.

Using only tor right now, a user needs to use a clearnet service
that does not scrape consensus, or one not fronted by services
doing similar to CloudFlare's spiteful default tor blocking policy,
or find a lucky exit within whatever geolocation game the clearnet
service uses, or get lucky through traditional vpn or proxy.

But those are only fun statistical hacks, not real long term solutions
to the underlying problem.

It's unfortunate that such braindead blocking, stupid policy regimes,
sites refusal to developing creative solutions [1] for so many world's
users legitimate privacy, info risk, anonymity needs... often results
in users accounts being locked out and escalated into forcing disclosure
of users private info and ID to sites to unlock them, thus exposing
users to ongoing long term fraud, cost, and stress when that info
(in most cases truly unnecessary to collect) is eventually shared
misused and stolen by both sites and criminals... or outright auto
deletion of user's valued account, built up social networks, etc...
all for doing nothing wrong, and harming no one or thing.
Death by DriveByExit :(
And really shameful to deny world's users the right to simply read
a website, be it social, commercial, information, etc or even sadly
their own tax-theft funded governmental public sites doing this
blocking too.


There are some related projects, best practice, as well...

https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor
https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access

Positive outreach and direct engagement by Tor community
is key here, and perhaps not enough of that is happening,
at least not publicly. It's a big enough issue that it really needs
a dedicated, active, allied, and even funded subproject...
a MegaProject that needs to happen.


[1] Such as forfeitable cryptocurrency and mailed-in cash
deposits refundable in time, increasing account priviledges
and features based on account age and activity, community
moderation and behaviour support within the sites, opensource
third party tracking-free local SecurImage style captcha throughout
a sites features, privacy preserving non-SMS non-Google/Apple
pure TOTP authenticator protocols, PGP recovery, letting
users simply *read* websites without any hindrance,
while utilizing these methods only for *write* operations,
etc and so many more ways you can envision...


Cc'd for awareness and inclusion. *Please remove tor-dev
and tor-relays, and move this to tor-talk or tor-access
for ongoing discussion and progress. Thanks.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Controller: text connection vs SNMP

[grarpamp]

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
usually richer and more capable, but harder to parse
(Juniper being more programmatic), and requires downstream
development to speak to each vendor's shell in automated fashion.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 like managing the
onion service ID itself too, rather than just authentication
for fetching or connecting to it.

Part of problem may be brain grouping of the underscores.

"onion" "client|service" "auth" "add|del|view"
"onion" "client|service auth" "add|del|view"
"onion client|service" "auth" "add|del|view"


> If you want the least specific left and the most specific right, I think
> ONION_AUTH_CLIENT_ADD and
> ONION_AUTH_SERVICE_ADD would be better.

Maybe your sense would be better...

"onion auth" for "client|service" do "add|del|view"

or if there's want to keep "onion" string as the MIB root...
"onion" re "auth" for "client|service" do "add|del|view"


Though seems mostly agreed on onion first and verb last,
so whatever works for people in the middle :)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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* filled with
all sorts of random things, doesn't sort,
and leads to documentation being scattered
as well, with assorted junk everywhere.


ONION_CLIENT_AUTH_ADD

is most clear... ONION (ok, what about onion),
CLIENT (ok, what about client), AUTH (ok, and...)
ADD (aha yes do that). And docs are self
ordering into nice sections.


ONION_CLIENT_ADD_AUTH

doesn't follow because it reverses the
last two thus breaking things again.


"We can't change"

Sometimes these positions can hold you back, allow
random in new things, expend mantenance on old chaos, etc.
If project codebases have a lot of legacy chaos, downstream
can appreciate and support refactoring in major releases,
even if they have to do a little work themselves to get that.
Announced mapping of legacy command support for removal
in next major releases can help there too.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 can't work out how an implementation is meant to know if a linefeed
> character is meant to be for line-wrapping or if it's meant to be the
> end of a keyword line.

Every "line" of the Document ends in "NL", the meaning of "NL"
depends, line buffer and matching is required for determination.

One distinction is if Keyword is only of KeywordChar+NL without WS.
If so, then thinking could be that you're into optional wrapped Objects.

However... where it can get dicey for third party parsers is
they might start interpreting '^-BEGIN' as another
KeywordLine with Argument, not least because KeywordChar
can contain '^-', and such parser won't necessarily know the
keyword dictionary (it would need to inherit that from tor library)
And for them to interpret say, '^[A-Za-z0-9]{64}$', as KeywordLine's
as well. Here is the tor specific magic regarding such knowledge...

228: When interpreting a Document, software MUST ignore
any KeywordLine that starts with a keyword it doesn't recognize;

And 224 is there meant to remove knowledge or confusion by
defining that case and triggering an Object at that moment
since it cannot be a KeywordLine...

224: A Keyword may not be "-BEGIN".

And even though "220: MAY wrap" may seem to allow otherwise
by appending *in-the-line* the "EndLine" string, it alone being the
end of Object trigger, "Document" writers should probably ensure
that any of their "NOT wrapped" "Base64-encoded-data" strings
have an NL at the end of it, so no inefficient char parsing required.


Perhaps some above is part of what you may be experiencing.


Nit
226: s/keyword/Keyword/
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Friendliness Scanner

[grarpamp]

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

You may be interested in this coupled pair of projects that
may be studying a similar question from a different perspective.
Note their needs list which might include integrating elements
of your platform, OONI, etc.

https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe
https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor

> In order to do this, we first must
> get an approximation of ground-truth data of how a given website should
> work. We then need to compare it to how the website works on the TB to
> determine any changes.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 reached some preset or unusual
threshold, thus becoming reportable.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 Connectivity Using Concurrency
https://tools.ietf.org/html/rfc8305

You probably want to reference it in
any relavant proposal, ticket, pull.


Below is of minor import...

Default Address Selection for Internet Protocol Version 6 (IPv6)
https://tools.ietf.org/html/rfc6724
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 plaintext off to other places, e2e TLS
is good there.
- Onionland does have some PKI, CA, pinning, and
tor signing infrastructures.
- Admins might want to play, learn, and do it just
because they can.

The browser either has options to import and trust an
onion sig over a cert, or you need to add it, or skip it
and use today's typical cert methods.

The concepts apply to both v2 and v3 onions.

> Would this approach work?

Manually for you, and by users, loading and configuring things, yes.
Automagically, browser would need to fetch pubkeys from
controller hsdir consensus, observatories, or other methods.

> Would it be worth the effort?

For whatever ca / pki structures are already good for, or not.
And might help against the rewriting onion proxies...
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 traffic retries sequence nums id nums
same tor node sets, etc. Controller should accept
pre and post interface change signals too.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Relay Guide Disagreements

[grarpamp]

> /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 ensuring safely collision free, like...

/TorRelayGuide/TorRelayGuide
/TorRelayGuide/DebianUbuntu
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 you do, try to wrap your lines at around 72 chars.

> AutoIt uses tokenization during compilation which adds random data to the 
> binary thus making it impossible to have reproducible builds.

Some projects that are interested in reproducibility
choose to document exceptions. So long as the diffs
don't actually do anything, and aren't a huge mess,
potential users checking reproducibility can cross
them out of the diffs they see on their end.

See if folks there have input on that.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 want to go a few cycles of feedback and development
with users on the wiki and the tor-talk / tor-relays lists before ready
to having it appear on website "projects" list.

Have fun :)


Projects that distribute binaries should of course be open source,
and reproducible per build instructions included with their source.
The concept is here...

https://wikipedia.org/wiki/Deterministic_compilation
https://reproducible-builds.org/
https://twitter.com/ReproBuilds
https://diffoscope.org/

https://wiki.debian.org/ReproducibleBuilds
https://tails.boum.org/blueprint/reproducible_builds/
https://signal.org/blog/reproducible-android/
https://wiki.freebsd.org/ReproducibleBuilds
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 when generating torrc
> files with relayor and I would like to document the impact
> of my bug (if there is any).

I posting somewhere about normalizing IPv6 address format,
it might have listed the RFC, for which the man page and code was
probably inconsistant. Similar to how fingerprints are a mess.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 heavy browser / wget / specific application apparatus or wasting
resources establishing TCP connections to the services themselves,
and for debugging tor client and network itself independant from
all such other tools, and helpful for "Why can't I connect" questions
from users, etc.

Further, a minimum request and result option semantics of
HSFETCH regarding the above were roughly specified previously...

HSFETCH  [fetch_mode] [output_each] [raw_desc]
[sync_here] [update_cache]
 as integrated with vN-DescId and SERVER= elements

General operation
- fetch mode: 0 default client resolution method, 1 force from network [3 only,
  do not recurse to cache], 2 force from cache [4 only, do not recurse
to network]
- source of the returned descriptor: network, or local cache
- network may have different data than cache so [update_cache] or not,
default yes
- result status of the fetch [a]: ok found, 404 not found, network
failure + why: reason
- status of the descriptor [a]: ok good, bad + why: crypto failed, expired,
  parsing data type, truncated, corrupt, etc
- decoding and printing out all fields of the returned descriptor,
  optionally also print the whole descriptor as received, regardless of any bad
  status, in hex [raw_desc] to further help debugging and other uses
For each HSDir by respective HSDir identifier [output_each=true]
- above result status of the fetch for each HSDir queried (typically six)
- above status of the descriptor from each responding HSDir
- above decoding and printing for each responding HSDir [output_each=verbose]

[a] These should be tagged 0 if all sources / HSDirs were ok, or 1 if an
ok descriptor was ultimately able to be returned to the fetch but some of
the sources / HSDirs had negatives thus pointing to further investigation,
or 2 if none were ok (and print the status if all six had same status, or
print "various" if they varied).

Since nodes may be performing other tasks in parallel, even over the
same onions, and due to various mandatory modes and sources being
selected, and network delays, it is very helpful and unambiguous if the
output is selectably synchronus to this command and console [sync_here],
thus leaving the HS_DESC / HS_DESC_CONTENT event streams doing their
thing if so enabled possibly on / for other control connections / monitors.
A command instance identifier should be added to be returned to match
up with respective event logstream (which would otherwise perhaps be
identified as "socks / tunnel / trans / dns / natd / etc" for those sources),
but that does not replace utility of [sync_here] for lesser capable
users or cases.

Future applications may (and perhaps already do) use HSDir descriptor
mechanism as their own datastore via HSPOST, for which similar
HSFETCH models would be useful, thus good to consider herein,
certainly as an extensible.

There were a tickets and emails somewhere on these concepts so
that they could be further and better implemented. Some elements
were committed, others remain :)

> It is the main reason it hasn't been done that is for a lack of use case. The
> HSFETCH for v3 is much more tricky in terms of engineering and interface thus
> we decided to implement it on the "need it basis".
>
> If OnionBalance actually needs it for v3, then we should try to get that on
> the roadmap.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 regular-expression
> matching of v2/3 addresses, and so far this is the winner:
>
>   "\\b([a-z2-7]{16}(?:[a-z2-7]{40})?\\.onion)\\b"

Did you post the results of the various RE engines and RE's somewhere?
Some of the onion services out there might find it useful in their backend work.

> ...and it's already in the codebase at
> https://github.com/alecmuffett/eotk/blob/master/templates.d/nginx.conf.txt#L299
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 about malicious HSDirs.

The publisher of the onion is the one who decides which to use
and what level of concern / tech applies to their use case.
In onionland, there seems to be little knowledge of v3, thus little worry
about v2 in cases where v3 would actually apply to benefit, that's bad.
And mooting of v3 in cases where it doesn't much benefit use case.
Rather than removing v2 support from the code [1]...
- the risk / benefit / tradeoffs / ux / uses of v2 vs v3 should be widely
publicized to educate about v3.
- common tools and applications such as ricochet, onionshare,
onioncat, onionvpn, bittorrent, securedrop, control, stem, nyx, etc
should add v3 support, thus also feeding back into education.
- some future release should change the default
documentation and operation inflection from v2 to v3.
At that point if a user goes to create an onion, everything
should lead to and result in them having created a v3,
other than a standalone v2 reference section in manpage on how
to create v2 onions, and continue v2 dirservices support, etc [1].

[1] v2 does have legitimate long term use cases exists,
there's a ticket opened for extended nonremoval support of v2.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 are sometimes
needed for both others and self.

A reachability test would have both listen and talk
config parameters, and even meta needs.

Like most tools of its vintage, tor started with few knobs,
configurability often came slowly as use case bugs.

'Address' might have multi role of...
- default network interface chooser
- embed this metadata in communications / consensus for others
- for self, tell daemon who it is, where to reach self, etc

'Address' is not documented as supporting IPv6.

Seems in the above may be what you're seeing.
Maybe some more config abstraction or docs would help.

'self-test' and 'reachab' appear a few times
in limited context in the manpage.


BTW: Hyphenating these two will conform the entire
codebase to the 'self-test' form for those searching it...

tor-0.3.2.10/src/or/router.c:1461:/* XXX IPv6 self testing */
tor-0.3.2.10/src/or/router.c:1470:  /* XXX IPv6 self testing */
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Setting NumEntryGuards=2

[grarpamp]

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
> time. These are completely different data retention resolutions, and
> if the netflow padding works as intended, dumping traffic onto an existing
> connection will be rolled up into all other traffic during that hour, or
> longer. At large scale, routers will likely be recording flows at just
> the connection level only, if that.
>
> What this means in practice is the ability for an adversary to go to
> large ISPs and say "Hey, give me connection logs you already have/can
> easily generate for these IPs during this specific time period" instead
> of "Hey, install this custom black box monitoring equipment for me and
> let me get arbitrary reports from it whenever I want". I know ISPs that
> have received and refused the black box request case because it was too
> intrusive. I also know ISPs that have given records over in the
> connection-level case.

Yes it's important to distinguish specific "netflow" style of records
analysis, from more general statistical traffic analysis of packets
flowing through a network, even if only from a limited to degenerate
number (2) of observation / targeting points. Even the simplest of
overlay networks could be considered at least a start against
the former. While the latter is a hard problem for nearly all of todays
networks and why few if any can claim to have resistance to anything
resembling GPA / GAA. Listing proposed solutions to the latter,
and why adoption of any of them into any overlay (or base layer)
network be it existing or new,  doesn't seem to really be happening
yet... a fine topic for another thread.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] 3.2.10 compiler warnings

[grarpamp]

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 mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] 3.2.10 compiler warnings

[grarpamp]

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 function
src/or/connection.c:1883: warning: passing argument 1 of 'TO_OR_CONN'
discards qualifiers from pointer target type
src/or/conscache.c:426: warning: passing argument 2 of
'consensus_cache_entry_map' discards qualifiers from pointer target
type
src/or/control.c:6815: warning: passing argument 1 of 'TO_OR_CONN'
discards qualifiers from pointer target type
src/or/scheduler.c:577: warning: format '%ld' expects type 'long int',
but argument 5 has type 'time_t'
src/or/connection.c:1883: warning: passing argument 1 of 'TO_OR_CONN'
discards qualifiers from pointer target type
src/or/conscache.c:426: warning: passing argument 2 of
'consensus_cache_entry_map' discards qualifiers from pointer target
type
src/or/control.c:6815: warning: passing argument 1 of 'TO_OR_CONN'
discards qualifiers from pointer target type
src/or/scheduler.c:577: warning: format '%ld' expects type 'long int',
but argument 5 has type 'time_t'
src/test/vote_descriptors.inc:93: warning: string length '4135' is
greater than the length '4095' ISO C99 compilers are required to
support
src/test/test_hs_descriptor.inc:224: warning: string length '14104' is
greater than the length '4095' ISO C99 compilers are required to
support
src/test/test_microdesc.c:648: warning: string length '5844' is
greater than the length '4095' ISO C99 compilers are required to
support
src/test/test_descriptors.inc:305: warning: string length '10571' is
greater than the length '4095' ISO C99 compilers are required to
support
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 only
the feature and bug topics described above...

"discussion regarding Tor development"
"Development related discussion list"
"for discussion by the developers"

> unwelcoming to new contributors.
> Criticising how people choose to volunteer their time

Hardly. At least one email was newthreaded and deattributed,
using no monikers or personal pronouns, being void of any directives
or aggressive / abusive speech, and surely naught but positing
free and open questions.

> doesn't help us develop tor.

Nay but benefit... It can help make developers stronger through providing
perhaps a rarely present oppurtunity outside the code routine for
self thought, reflection and review, to reaffirm or even adapt / modify
ones own course and efforts.

This has been noted as "interesting" by, and received "thank you"
from, at least one tor developer.

Should we not welcome and collaborate with all who might have
and allow for such occaisional thought time... are they not the
most welcome of any devs.

- A fourth, the list... "is very low traffic"

As any such reflection therein should perhaps be.

> I want everyone to be free to express themselves

As all are.

> we need to stick to that purpose.

For were there to be no such general prevailing focus on the
tech at hand, there might be few, and lesser, agnostic tools.

To wit, one lesser...

> #endif

nullius.c:1:2: error: #endif without #if

;)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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

Folks in convo before have covered some of these areas
and more that one could surely find or think of...

Philosophical...

Why does someone want to support and develop for Tor, or any other
overlay p2p anonymity network, or crypto, for that matter?
When even a fix to the manpage could be read and used by onion users
and operators, same for metrics, lists, or any other part of the ecosystem.
Does one fear "bad" things, association, or support "good" things?
Does freespeech, anonymity, privacy, human rights sound "good"?
What is "bad"? Censorship? Theft, Dictatorships, Police States,
whether one's own, that of the Enemy, or that of the Oppressed?
Cryptocurrency, anonymity, free markets, privacy, messaging... "bad"?
"Good" [only] when used to defeat "bad" things inside or outside
of [mal]functional democracies that assert majority force over
minorities who have forced no one? Ricochet, Signal, GPG... "bad"?
New technology that forces change over old entrenched ways... "bad"?
Are anonymous forums where professional therapists give pro bono
counseling to even the most reviled, depraved, criminal, socially
scarlet lettered and outcast... "bad"? Materials and talk of religion?
Are datamining, traffic archiving, exploits, cleartext... "good"?
Tor has exits... do people realize how much of both what they like
to "support", and abhor, travels over those exits? The variety of
traffic there is no different than onions. Should exits be unsupported?
What about the internet, or printing presses, should those tools
be unsupported? Are they "bad", get their makers looked askew?
Onions, exits, internet, presses, hammers... all simply agnostic
tools. Tools can be used to build great things, to defend, or to
wield in bloody murder.
And what of biases over certain agnostic tools instead of over the
separate "good" or "bad" uses of them? Do other tool builders and
users have to wonder if their tools are being compromised by those
with such biases?
What of when those with biases end up needing the tools themselves,
what will be the tool quality, or their ability to do "good" with them?
Have people taken the time to explore the onion space to find and
participate in all the "good" things they like therein, to create and
grow them, or even engage in counsel and advocacy against the "bad"?
What tools would be needed to do that?

Yes, people are free to work on what they like...
including giving deep thought as to what they like and don't, and
why, and how supporting agnostic tools can actually fit with that.

Are not your pens tools?
Who likes those?
Who supports those?
What if they didn't?
Pens... write code.


Tech, fun, politic...

Amounting to consideration feature X may prevent or diminish a
better archictecture on balance for some higher importance feature Y.
That should be covered open devops as usual.

Or if the *technology* or *code* of eg: eepsites onions, or other
subsets of various projects are not in their interest or knowledge
practice area. Ok.

Or if the features provided by any overlay network or tool are
deemed flawed, and the technical or political effort to get them
fixed, or rearchitecture, or correctly advertised, or called out
within as bunk, is too high, therein it may be better to abandon
them and or speak out freely as such.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Relay diversity master thesis

[grarpamp]

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: 
>> https://drive.google.com/open?id=1XEOSS29owavKJ_cJJAVaPiJe34Ez6XXx
>> The poster: 
>> https://drive.google.com/open?id=1BlF2U-Kexyz6ihVSqvsVHv4PUsvXATc4

> In particular, operators that could perform end-to-end correlation?

> Have you considered the relay's Operating System?

If considering as yet non tor daemon, non measured, non consensus voted
things like operators and OS, then you should extend research into similar
meta parameters about the relays themselves such as datacenter hosted vs
cable/dsl/fiber "home" relays, country locations, opposing legal jurisdictions,
operation by "known" or "trusted" operators / entities or not, by
working / fake / no
contact info, by any PKI Web Of Trust asserted among operators, funding
sources, employer / corporate / political / other affiliations,
statistical analysis
of historical relay "presence" on the network (add/drop/uptime, nicknames,
movement, versions, bulk turnups, correlation groups, etc), and many more
possible metas that people should think up and add to this list.

That research then followed by development of third party subscription
lists of categorized / ranked relays the user or tor daemon may further
pluggably select from when choosing nodes to path through.

There have been posts on tor-relays@ and tor-talk@ that mention more
about these sorts of meta parameters. AFAIK, no one has done any
research into them or their potential impact / benefits, whether to particularly
affected, or for plain preferential choice users, or to the network as a whole.
So the chance of a first good paper in the area awaits whoever does that
meta analysis project.

[xpost for open project oppurtunity]
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Rust rewrite help

[grarpamp]

> 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 mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 proper.
Users report them when found, others search for them via
exitmap, some create and use their own methods.
Eventually they're validated / rejected up to the dirauths.
If you've found suspected bad relays, report them to
bad-rel...@lists.torproject.org. Same for any ideas
or tools you might be working on and like to share.
You can search bad-relays, badexit, exitmap in wiki
below for a little more info.

https://trac.torproject.org/
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

>> 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 actually establishing circuits and
> fetching content over each exit relay.
>
> I just finished an exitmap scan and found 17
> exit relays that exit from
> an IP address that is different from what's listed in the consensus:

This mode of operation, regardless of how it happens, is not in
itself a problem, nor cause for alarm. In fact, the nature of these
"exit IP different than ORPort" relays can and often does assist
users in circumventing censorship... a fundamental use case of Tor.
For instance, the arbitrary automated and blind blocking via dumb
blocklists that prevent even such most basic user activity and human
right to knowledge as simply reading websites via Tor. Such blocking
examples can often be found here:
https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlockingTor

It's also entirely up to the exit operator to determine if the
third party non contractual / SLA exonerator service is of any
particular use or benefit to them or not... perhaps they have other
notary means, or are immune or not subject to any such legal or
jurisdictional issues, for which it becomes moot.

Similarly, realtime TorDNSEL and the like could be considered
to be censorship enabling tools.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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
> https://lists.torproject.org/pipermail/tor-project/2017-November/001564.html

There was someone in dev / talk maybe ~2 years ago that
wrote up a rather complete overview that got a lot of +1 from
people, think it ended up in pdf format. You could search
back for pdf links and maybe find it.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] anonbib

[grarpamp]

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 bloat... just the bib / meta / hash info and links.
Perhaps the links would point to files on the joint webserver.
Mirrors could clone the git and rsync the files.
Primary video links could be out to youtube.
Secondary sets of links that require clients could go to IPFS
or wherever for both papers and videos, even torrent magnet
infohash, seeding bandwidth could be shared across projects
as well.

> If you don't go for something like Mediagoblin

> exist. Asking CCC for hosting would be another choice, for
> their media they have a good amount of mirrors.

Whatever works.

> Should we
> track down more of them to ask the groups and people
> running them if they want to get involved?

If in the crypto privacy messaging overlay etc etc etc spaces,
it could be beneficial to at least send them a link to this thread.
Since each can freely tag to their own desire / view, and saves
maintenance it could be a hit.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] anonbib

[grarpamp]

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 client would offload from the bib.

There doesn't seem to be much of a data loss issue now,
papers with broken links are still refindable and fixable
if searched for hard enough, no?

But it might be said there's organization, maintenance, and
wider audience utility issues with current bibs.

However
- Once a better bib gets made, someone should consider
pushing the dataset into IPFS, gnunet, storj, whatever.
Object hash deduplicated systems among them are storage
efficient, no matter how many people push the same thing.
- Since most video presentation data exists only on youtube
(aka: google) at their whim, I assign high risk of loss to that
community corpus. It's a mess. All projects should be publishing
local copies of theirs for mirroring. Also, it's hard to autodedupe
down from youtube since they embed uniques per download / view.
- Projects should self host, or at least dual home themselves,
in their own overlays. for reference and other uses.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] anonbib

[grarpamp]

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

http://open-zfs.org/w/images/b/b3/03-OpenZFS_2017_-_ZStandard_in_ZFS.pdf
https://www.youtube.com/watch?v=hWnWEitDPlM
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] anonbib

[grarpamp]

> 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 easily being able to find and read what other projects in the space
are referencing covered by now having a combined database itself.
- Maintaining effort of growing multiple bib systems covered by everyone
lending some minor time coding to the main bib project db itself,
freeing up time for each project to then focus on submit / tag
and reading / using the materials as the more beneficial result.

And so on.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] anonbib

[grarpamp]

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.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] (no subject)

[grarpamp]

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 blank.
You can learn more details by searching "email etiquette".
Thank you for volunteer.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tracing TCP Connections online..

[grarpamp]

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 the path...
in order to observe the results.
And it's old news.
As noted before, since Tor (and all other current anonymous overlays)
nodes do not perform their own independant buffering, reclocking and
contracting for expected hop parameters... this vulnerability will remain.

Anyone wanting to research, code, deploy, and present on
such countermeasures would certainly be welcomed.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Reverse Naming Proposals?

[grarpamp]

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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Circuit times

[grarpamp]

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

[grarpamp]

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, so to clearly include only that part of which
you are replying to. Do not "bulk quote" chains of replies.
- *Interleave* your replies within the physical lines others
have written so that what specific part you are replying
to is clear. "Reply in context."
- Use "text/plain UTF-8" encoding, disable all "HTML" when sending.
- Wrap message lines at roughly 68-72 characters long.
- Be aware of how changing subject line, and reply-to
and references headers can break threading, and use it
carefully.

For more info you can search "mailing list etiquette"
on any search engine.

Thanks.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 onion
> address which are displayed on non-HTTPS web pages.
>
> Increasingly these attackers are becoming more selective in their
> targeting. Some attackers are only targeting a handful of pre-configured
> pages. As a result, we often rely on Tor users to report bad exits and
> the URLs which are being targeted.
>
> In Firefox 51, Mozilla started to highlight HTTP pages containing
> password form fields as insecure [1]. This UI clearly and directly
> highlights the risk involved in communicating sensitive data over HTTP.
>
> I'd like to investigate ways that we can extend a similar UI to Tor
> Browser which highlight Bitcoin and onion addressed served over HTTP. I
> understand that implementing this type of Bitcoin and onion address
> detection would be less reliable than Firefox's password field
> detection. However even if unreliable it could increase safety and
> increase user awareness about the risks of non-secure transports.
>
> There is certainly significant design work that needs to be done to
> implement this feature. For example, .onion origins need be treated as
> secure, but only if they don't included resources from non-secure
> origins. We would also need to make the onion/bitcoin address detection
> reliable against active obfuscation attempts by malicious exits.
>
> https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/

Search OnionGatherer on this list for ui stuff.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 would be great to
> have a discussion about that.

It's suggested and welcome that all overlay networks publicly
review, audit, analyze, each others work and offerings. Unfortunately
that hasn't develop much yet in a formal dedicated as responsibility
manner among even the larger opensource community, or even
discussion if that is a good idea. (But there is some good work in
some projects out there lately of their own work... automated code
linting, and the rarer procured third party audit.)

Then shall we presume all our networks are equivalently secure?,
or equivalently flawed, as each network happens to advertise now and then.

This may leave the matter of partitioning up to the user to consider
pursuant to any note about that in the app documentation.

The app could enable simultaneous multihome based on commandline
options... --tor --i2p --cjdns --other, default [whatever] .
And of course all the ports / addresses / bindings would need to
be flexible.

On equivalent networks, presence is maybe a bigger issue than partitioning.
This includes concept to drop the network identity off the network itself,
or use new ID, not just managing announces to buddy list entries.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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

[grarpamp]

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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 users could use for key ops and translation.
Since those howto topics appear on the lists now and then.
We here might code up openssl, python functions, etc on the fly.
However beginning users are typically looking for simple purpose
dedicated tools, or example docs using prebuilt tools off the net.
This tends to apply to budding application development in onionland,
developing things that look at and use tor, etc.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

Some like $() over ``, or indenting line continuations too.
As in perl, tmtowtdi, no worries.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] tor 0.2.9.9 gcc 4.2.1

[grarpamp]

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
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 recognition
and parsing. So it's not all just about the browser brain urlbar.

GPU capacity hasn't hit 16 char yet, mnemonic
brain memory has, but that's only happened based on
address luck and/or GPU prefixing. We're more or less
at the limits, new random bits past 16 won't matter and
shouldn't be considered much an argument to brain relavance.
Some other brain layer will come along, and if not, there's
always search.

If version goes in address, I'd wary against putting it last.
A lot of things naturally sort and route and default based
on higher order bits appear prefixing on the left.. IPv4 IPv6
bitcoin PTR DHT filesystem unix tools... the list goes on.
A single leading character is not a problem and gives
plenty of bits of version capacity regardless of encoding.
Trailing version just plain feels shaky to rely on or to
advocate to the world as a new standard. Certainly
not without consultation with other anonymous overlay
projects as to their future needs and direction as well,
or to develop such an interop standard.

At least until bumping against DNS length limitations,
all lower case should be obvious, without symbolics,
without nonprintables, etc.
Try to stick to most common compatible [a-z0-9]
or less unless forced otherwise.

Don't try to create new parsing headaches for application
authors / porters to work around who might already
be using rather basic charsets and routines with
existing protocols.

Whatever works.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] tor 0.2.9.9 gcc 4.2.1

[grarpamp]

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 overflow does not
occur when assuming that (X - c) >= X is always true
src/test/test_dir.c:3828: warning: assuming signed overflow does not
occur when assuming that (X - c) >= X is always true
src/test/vote_descriptors.inc:93: warning: string length '4135' is
greater than the length '4095' ISO C99 compilers are required to
support
src/test/test_microdesc.c:654: warning: string length '5844' is
greater than the length '4095' ISO C99 compilers are required to
support
src/test/test_descriptors.inc:305: warning: string length '10571' is
greater than the length '4095' ISO C99 compilers are required to
support
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 (whether under prop224 or current onion) is
not necessarily (is not) one to one bidir binary, it's just a name-value map,
a forward lookup table, for which under that destruction, a 'name' could
just as well be an IPv6 address string. 'name', 'label', 'address'... all the
same in this case. Abstracting the bidir part, and authenticating the
previously one to one nature, is the challenge.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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' layer, can we not develop an IPv6 layer?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 function,
but is instead just like any other application exiting to clearnet over tor,
for which obaE is the correct sense.
Further, if one can DPI or otherwise identify ToT, it makes no difference
what interface or tag it comes from. So this is moot, no worries.

> Binding to a particular source port is a bad idea - as the 4-tuple of:

Yeah I was on some multiplexing crack there.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[grarpamp]

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 folks blogging related to the above...

http://mh7mkfvezts5j6yu.onion/2016/08/18/using-freenet-over-tor.html

This post outlines a method of using Freenet over Tor based on posts I
wrote on my Freenet hosted blog and subsequent discussions about it.
If you read my Freenet hosted blog there's little new here, I'm just
making it available on my non-freenet blog.
One issue I've had with Freenet is that it exposes your IP address to
peers. Recent law enforcement efforts to monitor Freenet have shown
that they have been able to obtain search warrants based on logging
requests for blocks of known data and associating them with IP
addresses. If law enforcement can do this, so can random bad people.
You can avoid exposing your IP address to random strangers on opennet
by using darknet but even then you have to trust your friends aren't
monitoring your requests. If it was possible to run Freenet over Tor
hidden services then only the hidden service address would be exposed
using this logging method. A problem is that Freenet uses UDP which
Tor does not support.
https://emu.freenetproject.org/pipermail/devl/2016-June/039056.html
A recent post on the Freenet development mailing list pointed out that
onioncat provides a virtual network over Tor and tunnels UDP. Using
the steps they provided, and some tweaks, it's possible to set up a
darknet node that doesn't expose its IP address. It uses the onioncat
generated IPv6 address for communicating with peers - and this address
is backed by a Tor hidden service.
The steps below outline how to set this up.
... details inside ...


https://lists.cpunks.org/pipermail/cypherpunks/2016-October/032674.html

I've been taking a somewhat different approach. I'm also using OnionCat,
but I focused first on anonymously reaching peers via the open Internet.
I have a node that hits the Internet through an "anonymous" VPS proxy.
The node reaches the proxy via IPv6 OpenVPN via OnionCat. The node binds
locally only to tun1, and in the proxy, tun1 forwards to eth0.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 around tomorrow,
or run their own certs.
And needs bypassed if users pin the site cert fingerprint in browser.

> Tor Browser
>   MUST fetch and interpret the policy

Big problem for any sort of debugging, observatory, geo selection,
estimated risk of compromised exit, or simply refusal by the user.
Must be disableable in browser config.

>The "fingerprint" element points to the
>hex-encoded, uppercase, 40-digit fingerprint of an exit relay, e.g.,
>9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645.

This should be lower case...
https://trac.torproject.org/projects/tor/ticket/12799

> The "signature" element
>   points to an Ed25519 signature, uppercase and hex-encoded.

Ditto.

> "start-policy" and "end-policy" are both constants
>   and meant to prevent an adversary from serving a client only a
>   partial list of pins.

This is https so it's unlikely and a bit moot, yet assuming it was
plaintext, the set couldn't be asserted anyways without sig
from site cert or from dnssec or even pgp.

>   The purpose of exit relay pinning is to protect a website's users
>  from malicious exit relays.

Better the site run an onion to offer cover all users of all web tools,
not just tbb, eliminate chance of compromised exit, and eliminate
the ISP / GPA clearnet gap. And though not as sneaky a way to get
more relays deployed, they can then still volunteer to run or pay for some.

>   If Tor Browser would attempt to fetch the ERP policy over n circuits

Perhaps costly / noisy without prebuilt circuits.

>   within a narrow time interval, suggesting that all these connections
>   disadvantage of this defence is that it can take a while until Tor

if max-age < (interval or determination) then bad.

> we could have Tor Browser *ask* the web server

Great for advertising demand for tor in logs.
Great for blocking tor.

>   host their exit relays topologically close to the content servers, to
>   mitigate the threat of network-level adversaries.

Moot given the implied traffic analyzing PA's.


other:

> (Minor point) Those are hexes, not digits. :)

[0-9A-F] are the complete set of *digits* making up base-16
"hex[adecimal]" *number* system. as are [0-7] base-8 "octal",
[a-z] base-26, [whatever-chars] base-whatever. Some RFC's
even refer to them as digits, 4291 IPv6 for example.
They're more properly called "symbols representing values",
spoken as digits, by aliens in their base [world].

> some sort of versioning, or specified the cryptosystem, etc.

Speaking of RFC, ERP may be an idea, but who are the
guniea pig supporting sponsor sites, and who's doing
the RFC, and prepared to pin this thing for years?

You could put the sites in the relay descriptors
for client choice, but they'd still need crosschecked
with site sigs, and could bloat consensus more.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[grarpamp]

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 it, or b) move it elsewhere and/or post a new
subject thread.

[1] Reasonably including OnionVPN and any other equivalent
IPv6 p2p onion tunnel(4) adapters as layered on, or integrated
natively with, hidden services. And possibly tie-ins of this with
other overlay networks, ie: garlicat.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[grarpamp]

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 more global
and random on demand distribution properties, and even mutually
co-interested long term storage nature of bittorrent, that's harder.

Today people can use onioncat to escape IPv4 address space limitations,
provide UDP transport, provide configuration free on demand any node to
any node IP network semantics for use by existing applications.
Mass bittorrent / bitcoin / p2p apps over a private network such as
HS / eep happen to typically need and match that.

> Yes but then you are suggesting TCP on top of TCP via TCP/IPv6/onion/TCP.

Onioncat is only one extra encapsulation layer. Of course if you run tcp
app over onioncat instead of udp app, you have to think about that too.
But being the top layer, onioncat itself does not have losses, ie any losses
come up from below clearnet --> tor --> ocat --> user.

> Do you know what happens when you get packet loss with that protocol layer 
> cake?
> Cascading retransmissions. Non-optimal, meaning shitty.

For certain applications, expecially bulk background transport, it's actually
quite useable in practice. And people do use voice / video / irc / ssh over
hidden / eep services... of course there are non-optimal systemic issues
there. People will use what they can [tolerate].

> You might be able to
> partially solve this by using a lossy queueing Tun device/application but that
> just makes me cringe.

That's pretty far beyond anywhere tor network design is
going anytime soon.

Buffering for reordering datagrams into a queue, maybe partially if the
user doesn't mind possible additional latency. Lossy... not in tcp layers.

Maybe in ideal world user would supply requirements as ifconfig
request to network, each interface providing different set, user
binds apps to interfaces as needed.
Sliders latency / bandwidth / loss - maybe represented as single
app type config param: voice, irc, bulk, torrent, network tolerant - or
by list of app names.
Or network would monitor and adapt to users traffic.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[grarpamp]

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 tool for NGO's involved in recording human
rights abuses in less than friendly countries and for the general
public to be able to be shielded from the evermore privacy negative
environment we live in...

We are looking for developers to join us and criticism from the community.


(Another fine non-strictly-TCP[v4] application potentially enabled by OnionCat.
Though they may not be aware of its applicability yet.)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 anyone actually actively throwing the full audit gamut
at X11 these days, or is it still just one giant pile of 30 year
legacy waiting to explode?

> Really, just fuck off and leave me alone.

Oh no, the concept of one toplevel sig over a pile of embedded
sigs and infrastructure underneath, is useful. Kindof like
how signing a monotone or git repository is useful... a single
and simply checkable root from which all crap piles floweth.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 of what to do with it to the next layer (in our setup Linux
> kernel based policy routing on the same host). There may be a much
> better approach do achieve this goal. I plan on writing up our setup
> (and the rationale behind it) along with the "works for me but is not
> ready for upstream inclusion" patch tomorrow.

Part of rationale could be 'Hi bigwigs... stats say we helped 83GB traffic
move strictly to clearnet today without severe issue, please keep us funded.'
Another part is simply traffic engineering bandwidth cost, and possibly
in your edu case I2 routing. ToS tagging is interesting approach. Though
I think for more common operators at hosters, the IP/port approach would
work better. Not to say both cannot be added :)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 router named
> "ins2" in my declared family; I'll use the nickname as is, but this may
> confuse clients.
> Sep 19 11:37:41.000 [notice] Your Tor server's identity key fingerprint
> is 'ins0 01A9258A46E97FF8B2CAC7910577862C14F2C524'
> Sep 19 11:38:34.000 [warn] You specified a server "ins1" by name, but
> the directory authorities do not have any key registered for this
> nickname -- so it could be used by any server, not just the one you
> meant. To make sure you get the same server in the future, refer to it
> by key, as "$CD9FD887A4572D46938640BA65F258851F1E418B".
> Sep 19 11:38:34.000 [warn] You specified a server "ins2" by name, but
> the directory authorities do not have any key registered for this
> nickname -- so it could be used by any server, not just the one you
> meant. To make sure you get the same server in the future, refer to it
> by key, as "$7C3AF46F77445A0B1E903A5AF5B730A05F127BFC".

A side note, unless you have a reason not to, or the other nodes
are offline, you should fix up the MyFamily lines in the configs of
your nodes, to at least save noise in your logs.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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.

> - [FC00]/8 is _reserved by the IANA_, and beyond that, CJDNS is already
> squatting on it. :/

As all their independant users are not really one 'AS number' like
entity where the concept of 'local' policy would then apply to all, CJDNS
does present some problems in this area. Possibly with interoperating
with other IPv6 based overlay networks and adapters / tunnels. I hope
they're aware of them. Unfortunately to fix I think they'd have to rearchitect,
or at least renumber to squat elsewhere... both being rather unpalatable
from their point of view. Specifically, if I recall, they're abusing the 'L' bit
in the RFC, squatting the undefined 0. I don't think so but would have to
double check if they're also stomping the 1. Obviously generating into
a proper L=1 /48 is not practical. As with the .onion and .i2p DNS
reservations, I'd highly suggest CJDNS apply to IANA for a special
/whatever they could then generate into.


Yes in general networks shouldn't ride on top of space others are
legitimately using per RFC, such as the ULA space. Even riding
on some unallocated unicast space outside 2000::/3 that IANA is
unlikely to ever allocate to the global IPv6 routing table of host
networks would be preferred over that. That is, if you don't apply
for a special purpose allocation.

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
https://tools.ietf.org/html/rfc4193
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 makes it very easy to give
> Tor its own subnet no-strings-attached, strictly grants a /48 prefix.
>
> As a result, I am faced with a choice between deeply suboptimal options:
>
> 1.) Use VirtualAddrNetworkIPv4, as I've done in the past. This results in
> _fewer_ addresses being available to Tor than an IPv6 /48, which I feel
> illustrates the issues with requiring a /40 quite clearly.
>
> 2.) Squat on some portion of the IPv6 address space I don't actually own.
> This is entirely unpalatable

This impacts with onioncat as well.
I'm curious as to any /40 rationale, though I suspect a historical
brainfart typo.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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
>> and
>> what the CPU utilization is. These kinds of information would be really
>> helpful.

I used to report CPU exhaustion when pushing 15-25 high circuit
flux application streams in parallel through a client and thus its guards.
To gather and characterize current limitations in an operational context
you might want to deploy a guard at your university and run some
clients through it, instrumenting various things, until something saturates.

I'd be interested in seeing estimates of what the net change in
network usable CPU headroom [1] is when adding relays using certain
fixed ratios of their own cpu/circuits and or cpu/clients and or
cpu/bandwidth capacities.

Perhaps in other words... we roughly know how a clients stream
over 3 or 6 hops might consume an additional 1Gbps added to
the network. But what does adding its CPU to the network
get us... and effect of clients/net on that. And with each box
added, are we adding the right ratio of CPU and bandwidth,
do we need a knob there to ensure optimum balanced benefit
to the net, or is it better to leave it float.


[1] Left over for network meta purposes like circuit construction,
directory services, consensus, parametric pathing computation, etc.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Alternative Implementations of Tor

[grarpamp]

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

[grarpamp]

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 subdomains and uppercase
patterns posted and resolving beyond this original pre224 spec,
where same is hardly widely documented and known.
ie: most untrained users think 0-9 is valid, perhaps even
some full UTF-8 charset.

Rather than trying to shorten crypto hashes or key encodings
for own sake, or for silly human reasons least important of which
is memorization belonging in another layer, consider actual
buffers in apps, shell input, 72 char file width, etc.

Prefixing for some anti-dos sounds nice but also
goes the way of Moore, and you can only soft
increase it without hard banning users with old
code and onion keys.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[grarpamp]

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

Onioncat is interested in finding way to extend IPv6 addressing
past prop224 for use by IPv6 native user applications.

There are some purely internal ideas for that. Yet to extent
an internal tor+onioncat solution may be difficult,
onioncat may need to develop or shell out to a non-native
mapping and lookup layer. Namecoin has been mentioned
among prebuilt potential solutions.

Note clearly namecoin usage here *not* for human DNS style
naming such as myeasyname.onion. But as a mapping between
crypto key of onion (descriptor, hsdir, etc) and character string
of (in format of) IPv6 address for use in IP / tunnel addressing.

And most certainly any external layer must be capable of having
nodes binding natively in the Tor / I2P / etc networks, and
preferably being strictly private entirely within them (like how
private Tor / I2P / Bitcoin nets can be deployed by generating
new authorities, keys, genesis, etc). Outproxy is not an option.

It's also not ideal to be expending resources on mining
whereas other form of simpler distributed registry network
may suffice onioncat purpose.

Anyhow, fyi as to this thread and any ideas / collab :)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

> 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 list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Torsocks workalikes

[grarpamp]

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
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[grarpamp]

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?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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, donated, managed relays... only wanted all of what
I paid for to be consumed. "Wished" it would be in alignment
with certain ideals, but realized that's not reality.

For more and different opinions from relays, you might want to
post to tor-relays@ referencing the archive url to this thread.

> Second, my idea does not touch Exit bandwidth at all. We will only deploy
> hidden services.

Yeah, it's freenet over tor. Makes for an interesting definition
of hidden service. Don't forget to add around 1000+ ms latency.

> Wasting resources is abusive. However, comparing bittorrent traffic to
> Freenet doesn't do it justice. Freenet is used by dissidents for freedom
> of speech and publishing small static files like blogs, not to share gigs
> of media files.

Anonymous uncensorable overlay networks, are "used" by
whoever, for whatever, limited only by the techinical and practical
capabilities of each network. There are many "gigs of media files"
being shared over freenet and other nets by many happy and even
wasteful users. This fact understandably burns the britches of
those who intend their network to be used only for some other
purposes. It happens.

There seems to be ongoing and growing interest around the
world in overlay nets and parallel wire[less] 'guerilla' nets,
and lots of room for improved and new code and models.
No worries here.

> [arma] the main rule is that if you're going to add traffic to tor, run
some relays to match
> [arma] for hidden services, that's 1MB/s of traffic onto 6 places, so 6MB/s

This has always been my position. Each user of these "free"
community powered networks has an impact. For some nets
this has readily calculable minimums, like tor and its 6x minimum
for exclusively non-exit (HS) use. Other nets or usage models
may be roughly estimated. Therefore each user of such networks
should know / learn the impact for their respective network.
And should realize that they are in a way obligated to return
the resources they consume, as otherwise their network will
not have headroom and their own experience will go downhill fast.

> Freenet has 10KiB/s minimum bandwidth requirement.

Note that the correct form for engineering, and apps interfacing
at the level of, network traffic rates... is bits (b), not bytes (B),
and decimal prefixes, not binary prefixes.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[grarpamp]

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
>> current HS onion <---> IPv6 addressing mechanism.
>>
>> They're looking at various backward compatibility options, as well
>> as possibly making side use of the HSDir DHT, or even integrating
>> more directly with the tor client.
>>
>
> Just FYI, I recently migrated all of I2P's spec proposals to the
> website, and came across a seven-year-old proposal that Bernhard wrote
> about improving I2P support in GarliCat:
>
> https://geti2p.net/spec/proposals/105-garlicat-name-translation
>
> I don't know how well it has aged, but given that Tor is now facing the
> same issues that I2P has, perhaps it can be of some use if resurrected
> from the dead :)

Thanks str4d, I think I remember that one.

There''s certainly a difference between underlying cryptographic
addressing, and human "DNS style" naming. Onion addresses,
even at 16 char or 80 bit, were always beyond most human scope.
I'm not too concerned about human addressing since that can
always be a layer in userland (though not as strong as something
tracing back to the underlying crypto), of course if it comes along with
any side layer deemed necessary for getting the crypto addressing
working between nodes under IPv6, that's a good bonus.


>>> But the tor-onions mailing list is to discuss the technical details
>>> running onion services.

Fyi, I'm still waiting to hear back on the status of the onioncat list.


>> onioncat. It's a way to get non-TCP between TorHS onions, thus in
>> the thread "Hidden datagram service".
>>
>> I think there are a nontrivial number of users interested in, and
>> using, non-strictly-TCP transport over an IPv6 tunnel interface.
>> For example, look at users of CJDNS...
>>
>> For which we should try to continue a way, in v2, to do that over
>> anonymous overlay network Tor / I2P.
>>
>
> There is already some work on doing this in I2P:
>
> https://github.com/majestrate/i2p-tools/tree/master/i2tun
> https://github.com/majestrate/i2p-tools/tree/master/pyi2tun
>
> I2P also natively supports non-TCP protocols if that helps (only
> datagrams implemented thus far).

You mean just UDP? How would you move ICMP, GRE, raw IP/packets?
Do you have to implement each one? That seems more work
than implementing a generic data conduit, or an IPv6 conduit (as
a more specific, host stack oriented, interoperable form).
Though yes UDP would be the most useful for people after TCP.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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,

> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

I'd only bother with what's in these two lists, primarily the Global False.
Otherwise you end up determining and maintaining your own "bogon"
style lists which was not really the original intent of tracking IETF provided
rfc1918 style "private" address space list. Thus I'd remove it.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 drives after establishing contact with
> journalists. Even on a fairly fast connection, 2.6TB would take quite a
> while...

That amount of data would take 27 days at 10Mbps.
Few would be willing to sit supervising in a hotseat that long
when they can physically mail 3TB for $100 and 8TB for $230.
Though they might spend 3 days pushing 100Mbps via shells, etc.
Overlay networks move data reasonably well, and reliability
could be handled by chunking protocols. Available link
speeds (thus path speeds) are likely to be limiting factor,
ie: 10Mbps limits you to 100GiB a day. Though at 1Mbps,
DVD torrenting on say I2P seems to be a thing.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 it to a fixed falloff pattern more like...

0.2.4.27
0.2.5.11
0.2.5.12
0.2.6.8
0.2.6.9
0.2.6.10
0.2.7.3-rc
0.2.7.4-rc
0.2.7.5
0.2.7.6
0.2.8.1-alpha

... to be made shorter by dropping any with security issues,
refill with future releases. Point: stay current.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 to snooping / modification. HTTP, POP3,
NNTP, etc. And if the cert is MITM or server faked, so is TLS.
A map to a honeypot of passwords [telnet pop3 ...] would be fun.

> Alternatively, is there a way to determine what protocols are being used
> over Tor and their popularity?

That might guide which protocol to develop module for, along with
thinking of what payoff for snooping / modification that proto is.
Note tor claims such traffic analysis research is likely too
sensitive to conduct, even though people privately conduct
it all the time.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 (
> http://www.pcworld.com/article/3037180/security/tor-users-increasingly-treated-like-second-class-web-citizens.html
> )
>  and it was about tor users getting blocked from accessing alot of website.
> but after giving this some thought i think i came up with a possible
> solution to the problem :there is a thing called bridges, they are used to
> access the tor network without your isp knowing that you use tor, but if
> you can use those proxies to enter the network, it might also be possible
> to exit the network with them. But then we face a second challenge, the
> exit nodes have to be configured in such a way that it will relay traffic
> to such a bridge, so the exit node owners also need to know the ip of the
> bridge. While this doesn't seem difficult to do, it can become difficult.
> You see if the bridges are published on a public list(like normal bridges
> are) then the blocking sites in question will be able to block those
> address too. While this also posses a problem, a possible solution could be
> found in something called flashproxies, flashproxies are bridges with a
> really short life span, they are created and destroyed fairly swiftly, when
> this is done in a rapid pace, they become really hard to block because the
> ip changes all the time. So if the exit nodes can be configured to make use
> of such flash proxies, then the problem could be solved. I Must admit that
> not an expert on this or anything, and it needs alot of more thought, but
> it could work. so i was wondering if there are any experts who could help
> me with thinking out this subject and maybe confirm if this idea could
> work.

Skipping that whoever wants to enumerate, test, block, and share
lists of the IP of your final hop will find a way to do so...

"flashproxies"
- are essentially illegal to use as the operator got stupid, and
didn't gave permission.
- are unstable as were never intentionally provisioned, and the
operators get smart when abuse reports and shut them off.
- proxy lists are going to be a pain for you to scrape and maintain

Options
- run your own volunteer network of last hop "proxies" / bridges
- buy them from AWS or wherever "meek" style
- partner with or plug into already existing networks of those
- get tor relays or bridges to do this

I previously wrote in archives that exit relays could bind OpenVPN
to extra IP's they configure on their exit relay boxes. Tor daemon
has nothing to do with those IP so they never appear in tor's easily
blacklistable consensus. Users then OpenVPN over tor to those via
use of the relay fingerprint to reach vpn terminator IP over relay
localhost to save bandwidth, and on out to clearnet.

You can OpenVPN to some list of onions if you don't feel like listing
the relay fingerprints / extra input IP's on wikis. But it's not going
to stop dedicated blacklisters, and onion doubles bandwidth use.
However it could also be used by non-exits that for whatever reason
didn't want to be a tor-exit but did want to offer exit via some
remote third party vpn service. And strictly social sharing on
forums etc could happen for distribution.

There are already some exits that for various reasons, intentional
or other, do not exit from their OR IP. That is a feature that some
tor users do now find and use. And relays don't offer OpenVPN yet
which would also give users more than just IPv4-TCP exit scheme.

Though it is integrated somewhat, I2P has this manual sort of exit
offering model with false.i2p and a few other nodes.


[Doesn't seem to require daemon dev work, updated subject, continuing
thread reply to relays and talk.]
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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
traffic analysis.

https://en.wikipedia.org/wiki/Latency_(engineering)

Higher global jitter might help, but circuit orientation at
guards and exits through to the clients seems to nullify that.

https://en.wikipedia.org/wiki/Jitter

For which an idea may to become packet switching, which
is really no longer Tor.

https://en.wikipedia.org/wiki/Packet_switching

Link padding seems the next real step but I've not put enough
reading to it, only have idea to read about. Nor do I yet review about
Tor padding proposal as sufficient or not, sorry.

As it is not the Tor original model design maybe some other
network will take this analysis / padding issue up before then.
I've no idea.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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 traffic.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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.

> outbound bind address. Exit binding as distinct option might be
> useful, yet no one has defined a reasonable scenario for such utility.

another reason could be separating the exitIP as
sacrificial on abuse complaint and/or set in a freeforall dmz,
where orIP may more neutral and/or long term.

don't know if anyone has deployed on any of these potential reasons.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[grarpamp]

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]
[if RESULTs are buffers instead of immediate pipes]
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev