[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

Re: [tor-dev] Comments on proposal 279 (Name API)

[meejah]

It was suggested I post this to tor-dev; I prototyped a small thing
that allows the prop-279 APIs to be tested against actual-Tor without
changing Tor. That is, it does the "abuse the control-protocol" thing
but speaks to prop-279 style subprocesses.

This is just proof-of-concept and would need a little more fleshing out,
but should be sufficient to proceed with prototype implementations of
prop-279 clients.

   https://github.com/meejah/TorNS

-- 
meejah

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

[tor-dev] Adding Single Onion Service support to Bitcoin Core

[James Evans]

Core is preparing to support this new tor feature. Any helpful suggestions
would be appreciated. :)

https://github.com/bitcoin/bitcoin/issues/9836
https://github.com/bitcoin/bitcoin/pull/10161

Thanks for all the great onion work!
James
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Control-port filtering: can it have a reasonable threat model?

[dawuud]

> Yes, that is necessary.  I question, however, whether it is sufficient.

Sufficient for what purpose?

It *is* sufficient for the purpose of preventing Subgraph sandboxed
applications from escaping it's sandbox via the Tor control
port. Actually, one of the Subgraph guys figured this out and that's
why they wanted a Tor control port filter.

I can see how our intentions for this tool (roflcoptor) could have
been misleading since we never explicitly/publicly stated the above as
the motivation for tor control port filtration.

I think now that the other "Tor integrated Linux distributions" have more
or less caught up with Subgraph, I feel comfortable telling people how
easy it is to get tor to run arbitrary programs via the control port.

Looks like as per usual Yawning Angel did the exact correct thing and
made the Tor hardened browser bundle filter the control port to
disallow SETCONF.  Further, he mentioned to me on irc that the tor
proc is also sandboxed..  so yeah that sounds thorough and proper.


cheers from Montreal!

David Stainton



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

Re: [tor-dev] minimizing traffic for IoT Tor node over 3G/LTE

[nusenu]

Razvan Dragomirescu:
> Thank you, Proposal 140 sounds perfect for what I need, that would minimize
> traffic quite a bit! I see some code for it at
> https://gitweb.torproject.org/tor.git/log/?qt=grep=prop140 , I'm guessing
> it's not complete yet.

Relevant ticket:
https://trac.torproject.org/projects/tor/ticket/13339







-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comments on proposal 279 (Name API)

[Yawning Angel]

On Sat, 8 Apr 2017 08:47:51 +0100
Alec Muffett  wrote: 
> However: on this conference call it was made abundantly clear to all
> present - one could almost hear fingers being wagged - that it would
> be a bad thing for Onion addresses to (1) contain anything other than
> alphanumerics and non-leading-hyphens, (2) collide with IDNs and
> PunyCode.
> 
> Now: I flatly do not know where this is documented; it may possibly
> be some intersection of DNS and HTTP RFCs, and if we want to take the
> approach that "everything should be permitted unless it is explicitly
> forbidden!" then yes we should go chase those documents down so that
> we have rationales for our self-imposed bondage.

Ironically, I struggled with this a bit when I pushed for making tor
clients reject "obviously malformed" destinations right when they hit
the SOCKS server.

From what I remember/can tell, RFC 1912 has the rules on what a valid
`hostname` is, RFC 2181 suggests that DNS server implementations should
not enforce restrictions on what a valid `hostname` is, and from
experience enforcing strict RFC 1912 on the real internet breaks
`nytimes.com`.

RFC 6125 mandates "LDH Lables" (RFC 5890), but is only applicable to
TLS.

> However if we want to seek the path of least resistance and effort,
> the answer is obvious to any seasoned network administrator:
> 
> * alphanumeric
> * (whatever DNS label length)
> * (whatever DNS overall length)
> * single, and only single, dots at label separators
> * single, and only single, hyphens as spacers
> * (i'm trying to think if there are any more obvious constraints, but
> can't)
> 
> ...which will traipse merrily through any system one cares to name.

tor currently enforces most of those (label length is notably not
checked), and also allows:

 * `_` because `core3_euw1.fabrik.nytimes.com` despite what the RFCs
   say.

 * Trailing `.` used sometimes to make it explicit that the domain is
   absolute.

See: https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n1080

> That's a lovely idea; one more to add to the mix is the process
> documented at:
> 
> https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md
> 
> ...of hijacking addresses out of the DHCP network space and using
> them to configure interfaces with genuine, resolvable Onion names.
> It makes SSH and Apache configuration really clear when you can use
> the genuine onion address in configuration ("Listen") directives, etc.
> 
> But then that's /etc/hosts - that's *not* what goes to a Certificate
> authority to be signed, and it's the latter that the committees get
> exercised about.

Sure.

> Hyphenation, readability studies, boutique & frou-frou name schemes
> invented at the Tech University of Mercedes-Benz, and other shooting
> ourselves in the foot can, and should, come later. :-)

I'd be ok with, and would likely even advocate for "If you want your
naming system to be shipped with Tor Browser, it should follow certain
guidelines, including mandatory syntax, a label registry, and etc",
which is a matter of policy.

But that to me is orthogonal to "there should be a flexible way to
offload name resolution" (a matter of implementation).

In practical terms the tor code would need modifications to allow
anything super exotic anyway, and I doubt anything will actually get
shipped with Tor Browser[0] till long after prop 224 is fully
implemented.

Regards,

-- 
Yawning Angel

[0]: As much as I hate the fact that port 80 and 443 are basically the
only things that matter, that's basically the situation.


pgpmAOpHG284K.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] minimizing traffic for IoT Tor node over 3G/LTE

[Razvan Dragomirescu]

Thank you, Proposal 140 sounds perfect for what I need, that would minimize
traffic quite a bit! I see some code for it at
https://gitweb.torproject.org/tor.git/log/?qt=grep=prop140 , I'm guessing
it's not complete yet.

Thanks again,
Razvan

On Sat, Apr 8, 2017 at 12:43 PM, nusenu  wrote:

> > I am working on a project to create very small Tor nodes on embedded
> > devices connected over LTE or 3G.
>
> since you are concerned about bw usage I assume you talk about tor
> clients not relays.
>
> > I have it working fine with OpenWRT and
> > just 128MB of RAM, but the main issue is now the amount of data needed to
> > download the consensus. The consensus files appear to be around 2.3MB at
> > the moment and I think the default is to re-download every 3 hours, so
> > that's 18.4MB/day or 552MB/month. Is there any way to reduce this while
> > still maintaining good citizenship on the Tor network? Are there any
> > recommended options for low-bandwidth nodes?
>
> There is an ongoing effort to significantly reduce the bw overhead for
> tor clients on metered networks.
>
> Some improvements are supposed to land in tor 0.3.1.x.
>
>
> Relevant proposals:
>
> https://gitweb.torproject.org/torspec.git/tree/proposals/
> 140-consensus-diffs.txt
> https://gitweb.torproject.org/torspec.git/tree/proposals/
> 274-rotate-onion-keys-less.txt
> https://gitweb.torproject.org/torspec.git/tree/proposals/
> 275-md-published-time-is-silly.txt
> https://gitweb.torproject.org/torspec.git/tree/proposals/
> 276-lower-bw-granularity.txt
> https://gitweb.torproject.org/torspec.git/tree/proposals/
> 277-detect-id-sharing.txt
> https://gitweb.torproject.org/torspec.git/tree/proposals/
> 278-directory-compression-scheme-negotiation.txt
>
>
>
>
>
>
>
>
> --
> https://mastodon.social/@nusenu
> https://twitter.com/nusenu_
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] minimizing traffic for IoT Tor node over 3G/LTE

[nusenu]

> I am working on a project to create very small Tor nodes on embedded
> devices connected over LTE or 3G.

since you are concerned about bw usage I assume you talk about tor
clients not relays.

> I have it working fine with OpenWRT and
> just 128MB of RAM, but the main issue is now the amount of data needed to
> download the consensus. The consensus files appear to be around 2.3MB at
> the moment and I think the default is to re-download every 3 hours, so
> that's 18.4MB/day or 552MB/month. Is there any way to reduce this while
> still maintaining good citizenship on the Tor network? Are there any
> recommended options for low-bandwidth nodes?

There is an ongoing effort to significantly reduce the bw overhead for
tor clients on metered networks.

Some improvements are supposed to land in tor 0.3.1.x.


Relevant proposals:

https://gitweb.torproject.org/torspec.git/tree/proposals/140-consensus-diffs.txt
https://gitweb.torproject.org/torspec.git/tree/proposals/274-rotate-onion-keys-less.txt
https://gitweb.torproject.org/torspec.git/tree/proposals/275-md-published-time-is-silly.txt
https://gitweb.torproject.org/torspec.git/tree/proposals/276-lower-bw-granularity.txt
https://gitweb.torproject.org/torspec.git/tree/proposals/277-detect-id-sharing.txt
https://gitweb.torproject.org/torspec.git/tree/proposals/278-directory-compression-scheme-negotiation.txt








-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] minimizing traffic for IoT Tor node over 3G/LTE

[Razvan Dragomirescu]

Hello,

I am working on a project to create very small Tor nodes on embedded
devices connected over LTE or 3G. I have it working fine with OpenWRT and
just 128MB of RAM, but the main issue is now the amount of data needed to
download the consensus. The consensus files appear to be around 2.3MB at
the moment and I think the default is to re-download every 3 hours, so
that's 18.4MB/day or 552MB/month. Is there any way to reduce this while
still maintaining good citizenship on the Tor network? Are there any
recommended options for low-bandwidth nodes?

Thank you,
Razvan

--
Razvan Dragomirescu
Chief Technology Officer
Cayenne Graphics SRL
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comments on proposal 279 (Name API)

[Alec Muffett]

On 8 April 2017 at 03:23, Yawning Angel  wrote:

> On Fri, 7 Apr 2017 11:44:03 +0100
> Alec Muffett  wrote:
> > If I was in charge, I would say that we risk overthinking this, and it
> > would be better to:
> >
> >- mandate use of fully DNS-compliant syntax, including but not
> > limited to: acceptable max length, max label length, charset and
> > composition
>
> Fully DNS-compliant only limits max length and max label length, unless
> there's something that supersedes RFC 2181.


You have an excellent point, and I remember fondly the happy days at Sun's
Network Security Group when I would set the name of my workstation to "#"
in DNS and use it to break into people's machines because ".rhosts" did not
support comment characters in the way that people expected.

However: on this conference call it was made abundantly clear to all
present - one could almost hear fingers being wagged - that it would be a
bad thing for Onion addresses to (1) contain anything other than
alphanumerics and non-leading-hyphens, (2) collide with IDNs and PunyCode.

Now: I flatly do not know where this is documented; it may possibly be some
intersection of DNS and HTTP RFCs, and if we want to take the approach that
"everything should be permitted unless it is explicitly forbidden!" then
yes we should go chase those documents down so that we have rationales for
our self-imposed bondage.

However if we want to seek the path of least resistance and effort, the
answer is obvious to any seasoned network administrator:

* alphanumeric
* (whatever DNS label length)
* (whatever DNS overall length)
* single, and only single, dots at label separators
* single, and only single, hyphens as spacers
* (i'm trying to think if there are any more obvious constraints, but can't)

...which will traipse merrily through any system one cares to name.

I am purposely leaving specific "label" and "overall" lengths out of this
list because although the correct figures are googleable, they tend to
trigger citation wars and off-by-one arguments so it's safer to discuss
them symbolically.


I intentionally left a lot of this unspecified because one of the use
> cases I envisioned was an "/etc/hosts" analog that lets users easily:
>
>  * Stick all their hidden services under their own name hierarchy.
>
>eg: git.yawning -> .onion
>

(...elided...)

That's a lovely idea; one more to add to the mix is the process documented
at:

https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md

...of hijacking addresses out of the DHCP network space and using them to
configure interfaces with genuine, resolvable Onion names.  It makes SSH
and Apache configuration really clear when you can use the genuine onion
address in configuration ("Listen") directives, etc.

But then that's /etc/hosts - that's *not* what goes to a Certificate
authority to be signed, and it's the latter that the committees get
exercised about.

Onion addresses are not really hostnames, they're a machine-readable number
a-la IPv4 and IPv6, which - by amazing, fantastic fortitude - happen to be
exactly compliant with DNS which means that subdomains "work" where they
protocol passes them along in (eg: "Host:" header) metadata.

The Elders of the Internet (TM) did not have the wisdom to see that
"www.127.0.0.1" would be a useful thing; they put everything into tidy
buckets - layer 3 goes here, directory lookup goes there - and at the
outset broke decentralisation and imposed hierarchy by means of user
expectation.

Whomever the clever person was who unbroke it by making tordaemon ignore
"subdomains" should be honoured - they (accidentally?) re-merged the two
namespaces and - so long as Tor walks the knife-edge of being compliant in
both namespaces - then Onion addressing is in an amazing position:

* all the browser technologies which assume DNS can work without
modification
* this includes availability of HTTPS certificates
* and therefore all future web technologies like WebRTC
* but the addresses are end-to-end and self-created, thus obviating the
whip-hand of DNS censorship
* and onion services are effectively "published" (X.25 did similar)
reducing attack surfaces without firewalls / intermediation
* intermediation which Tor bypasses anyway, because NAT-punching /
Rendezvous, etc.

It's hard to express how amazing this situation is; it's really like
winding the clock back to the 1980s and getting a whole new network
architecture, for free, which supports all the modern bells and whistles,
all because of the Host header, SSL-compliance and fake onion subdomains.

This is why it's essential to get this right. :-)

Yawning wrote a bunch of stuff here, but I am gonna elide it and sent this
message to see if it changes anything, and then revisit.

I'll just finish by saying that I am very excited about:

  www.somethingexceefinglylonggoeshereandwearenotreallysureaboutformat.onion

...because we can complain about