Re: [tor-dev] When RFC 7686 and transparent proxies collide

[Alec Muffett]

Hi Shawn!

On Mon, 13 Nov 2023 at 15:54, Shawn Webb 
wrote:

> I agree that infoleaks, especially of .onion DNS requests, is
> problematic. However, I disagree that prohibiting it in broadly
> monocultured libraries (libcurl) is an advisable approach.
>

If Curl is outright banning ".onion" at the level of the Curl source code,
I would not support that on the grounds that are described in bullet point
2 of section 2, here, which I will requote in full:


*https://datatracker.ietf.org/doc/html/rfc7686#section-2
*

*2. Application Software: Applications (including proxies) that implement
> the Tor protocol MUST recognize .onion names as special by either accessing
> them directly or using a proxy (e.g., SOCKS [RFC1928]) to do so.
> Applications that do not implement the Tor protocol SHOULD generate an
> error upon the use of .onion and SHOULD NOT perform a DNS lookup.*


...but I will also note that I have not (maybe I missed it?) seen bullet
point 3 being referenced in this thread:

*3. Name Resolution APIs and Libraries: Resolvers MUST either respond to
> requests for .onion names by resolving them according to [tor-rendezvous]
> or by responding with NXDOMAIN [RFC1035].*


I see Curl/LibCurl in the context of an application (§2) which makes calls
into name resolution apis (§3).  I regret that the text of §2 ("...that do
not implement the Tor protocol...") is ambiguous in its scope, and would
prefer something about the app being incapable of dealing with and unaware
of the existence of multiple possible name-resolution namespaces, instead.

Likewise I feel that *"Applications that do not implement the Tor protocol
SHOULD generate an error"* would benefit from being rewritten to
acknowledge that the desirable error *may* come passively as a consequence
of the name resolution libraries that are called, rather than via some
manner of "policing" invocation of the .onion domain.

tldr: I feel it should not be up to curl/libcurl to be policing the use of
".onion" ... but I am very content for its chosen DNS-based name resolution
backends to be doing do so.

However convenient it may be to attempt to bolt ".onion" onto the DNS for
mobile or Whonix or whatever development, there's no avoiding that in
several ways it is both risky and unspecified to do that. I can't fix that
for anyone, but I also cannot deny that it's pushing water uphill to
attempt it.

My personal sense has always been that at some point in the future
systems-level Tor onion access might need to be provided via a network
interface that presents and routes AF_ONION addresses; but until then (and
per the linked video) new directions in DNS provide us with a secondary
possible solution: Those (mobile?) people who cannot get the benefit of a
solution via /etc/nsswitch.conf should probably have their handsets
reconfigured to do "DNS" lookup via DNS-over-HTTPS[1] to a local HTTPS
service that both understands and treats-in-isolation, all ".onion" lookups.

Of course this does not solve apps which do their own DNS resolution, yadda
yadda, but then there is no way no NSS to solve them, either; also this
points to the importance of a TCB being curated with a "systems"
perspective (including NSS integration?) rather than trying to bolt stuff
together to get to a merely "functional" solution.

Overall: long-term continuing to shoehorn Onions into DNS for
transparent-proxy name resolution is relentlessly moving towards being
actively painful. I feel that now would be a good time to embrace a
different, ideally standards-compliant / more-futureproof approach.

-a


[1] Fun reading on a related topic: https://github.com/alecmuffett/dohot









>
> While I can appreciate and understand the many nuances of this
> particular problem, it is one that is indeed difficult to solve.
>
> Are there other commonalities between "infoleaky" deployments that
> could be improved? It seems to me that outright prohibition should be
> a method of last resort. Are we already there?
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>


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

Re: [tor-dev] When RFC 7686 and transparent proxies collide

[Alec Muffett]

Hi! I'm one of the authors of RFC 7686.

Although myself and Appelbaum[1] are cited on it, the document is the
result of a huge amount of argument and input from many people (shout out
to Mark Nottingham most especially, whom I feel should have gotten an
author credit) on various IETF maillists, and against considerable pressure
from some in the DNS, ICANN and other naming communities who didn't want to
set a precedent nor open a gateway to "more exceptions for new TLDs".

Reading this thread I can confirm that transparent proxies (of several
implementations) were considered to be outside of the scope of the
specification, not by intention but rather as a consequence of the DNS
community being **extremely motivated** to prevent the existence or
official sanction for anything that could be construed as extending DNS by
default, without going through the full DNS standards processes.

There was (and, I suspect, remains) very much an attitude of DNS being
practically sacred and unamendable unless overseen by an elite priesthood
of experts, and as such all the "Tor" stuff was presented to them and to
the standards committees as being *"something utterly different from DNS,
really, we swear, honest, this is more of a namespace bookkeeping issue
than anything else"* — in order to prevent the standard being shot to death
by DNS zealots.

Also: the ".onion" resolutions which "leak" into the global DNS network
were at the time — and probably remain — both a nuisance and a huge
information leak that gets mined by various state security agencies; those
participants who perceived that as an issue saw the RFC as an issue to
address both the noise and the leak by drawing a very firm line between DNS
and Onion addressing, hence the text which is under discussion here.

Myself? I am looking at the application wants sympathetically, but with a
perspective of 36 years of Unix. To be frank I believe that the process we
went through and the points that were made during the RFC are prettymuch
valid, and I believe that using DNS as transport for a hack to resolve
Onion addresses is ill-advised, even massively dangerous, for the reasons
described.

I have sympathy for the DNS resolver community being explicit about banning
".onion" and I think that doing so would be good for Onion privacy; but
that doesn't mean that I find the *need* to resolve .onion addresses to a
virtual IP address to be illegitimate.

Back in the 1990s we used to deal with their being different namespaces for
different networks[2] using the /etc/nsswitch.conf service which was
literally designed[3] to address this kind of problem; the acronym stands
for "Name Service Switch"[4] and it's how local naming in huge intranets
used to be implemented.

As such, why not just build a small service to perform this mapping lookup
properly and splice it into nsswitch.conf, and save yourself from having to
police the DNS clients for data leakage re: "This IP address just tried to
look up `supersecretleakysite234567abcde.onion`"?

 - alec

[1] yes, I know
[2] see this https://www.youtube.com/watch?v=pebRZyg_bh8
[3] https://man7.org/linux/man-pages/man5/nsswitch.conf.5.html
[4] https://man7.org/linux/man-pages/man5/nss.5.html
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Service v2 Deprecation Timeline

[Alec Muffett]

On Tue, 16 Jun 2020 at 12:15, meskio  wrote:

> I'm wondering if it will make sense to use Onion-Location in V2 onion
> services
> to advertise the V3 onion. So existing known V2 services can use it to
> upgrade
> their users to V3.
>
> AFAIK right now tor-browser ignores the Onion-Location header if is
> already
> coming from an onion service. Will it make sense to stop ignoring it at
> least
> for V2 onion services?
>

Or the site could just issue a Location header and/or explicit redirect to
the v3 service?

After all, if the v2 site is compromised to the point where that's a
problem, then there are larger issues / "game over", etc.

-a
-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header

[Alec Muffett]

1) the best and proper way to redirect from site A to site B is to use
"Location:" and/or an appropriate 3xx code. It already works.

2) having an "h2o" ALPN for Alt-Svc would literally make things worse,
retard adoption, confuse implementations, break almost all of my future
plans for onionification of corporations, and generally make life a pain.
It's hard enough getting people to implement functionality in early stages
when there are merely bugs, let alone forcing them to jump through hoops to
implement special, redundant magical headers that literally do not serve
any additional functional value above the extant, open, standard, supported
ones.

3) if sites wish to follow Privacy International's example and redirect
from a DNS TLD to ".onion" then that is something they should implement at
layer 7, by dint of identifying whether the user has arrived over Tor. (See
below)

4) if sites want to advertise the existence of an alternate onion site by
leveraging some form of tor-specific browser pop down, then sure, knock
yourself out with a magical header but nobody in their right mind is going
to deploy it in the Enterprise. It would be a massive waste of human / tech
bandwidth and hassle. It would be far easier and cheaper instead to react
having first identified whether the user has arrived over Tor.

5) onion networking already works for h2 ALPN under alt-svc; please do not
mess this up by fragmenting it / imagining that it needs to take-on a
special syntax to reflect it's "onion nature". I get what you are saying,
it's very clever, but please: no. There is a vast amount of potential for
organisations to "turbocharge" their Tor user-experience by simply offering
an "h2" onion address amongst Alt-Svc when a user connects to them via an
exit node. Everything is already sufficiently disambiguated by the ".onion"
suffix. We're good.

6) a moment's consideration will illuminate that the underlying problem
here is the increasing fallacy which Tor continues to suffer, that sites
should/do not know that a user is arriving over Tor. That half of the
websites in the world should be kept in ignorance that a user is arriving
via Tor, while the other half - the popular sites by volume - actively want
to know that the user is arriving over Tor in order to optimise the user's
experience.

In short we have conflicting desires: some tor users want to pretend that
they are just some schmoe (sp?) running Firefox on Windows on a "random
machine somewhere on the internet" - e.g. a fat exit node run by Mozilla…

But any website that takes an interest (e.g. tracks Cloudflare's "xx-tor"
country geolocation, or whatever it is called) - regarding the reputation
of the source IP address will KNOW that the user is coming from Tor.

We live in a weird world where the Tor community still believes that
systems administrators don't have trivial access to IP reputation databases.

The world has changed since Tor was first invented; perhaps it's time that
we stopped trying to hide the fact that we are using Tor? Certainly we
should attempt to retain the uniformity across all tor users - everybody
using Firefox on Windows and so forth - but the fact that/when traffic
arrives from Tor is virtually unhideable.

Consciously sacrificing that myth would make uplift to onion networking so
much simpler.

- a
___
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?

[Alec Muffett]

On 27 April 2018 at 19:48, Damian Johnson  wrote:

> > OnionBalance requires STEM support for V3
>
> Hi Alec, would you mind clarifying what you need from Stem? As far as
> I'm aware Stem supports v3 onion service creation...
> ...
> I'm unaware of the ball being in my court on any v3 Onion Service
> stuff. If there's something I should have on my radar then please let
> me know!


Hi Damian!

That's awesome, and good to know - I first wrote that text a few months ago
(on the basis of David's comments in that ticket) and haven't revised it
since, so I am heartened to see progress.

However I am also not the best person to say what else will be needed,
because that would probably be Donncha re: the future of OnionBalance for
v3.

At the moment in OnionBalance the v2 Introduction Points of the
(predetermined) worker onions are passively scraped from the HSDir; the
descriptors are parsed, the IPs are blended and re-combined and re-signed
under the master onion key (eg: nytimes3xbfgragh) and then published back
to the HSDirs, with the result that NewYorkTimes-browsing clients end up
communicating with 1 of N possible "worker" daemons, thereby sharing the
load.

My understanding - and please jump in, if I am wrong - is that the
synthesis of a v3 descriptor which blends the introduction points of
several independent v3 "worker" Tor daemons will be a more complex affair
than the existing process, because (?) the "worker" tor daemons will
somehow have to be more actively involved - apparently they may have to
sign the v3 Introduction Points themselves, though I am not sure how that
will work for a blended descriptor? Multiple/distinct signatures, perhaps?
The last opportunity I had to speak with anyone (re: this) was more than 1
year ago, so I am rusty, and I apologise if I have gotten some details
wrong.

So: OnionBalance relies heavily upon Stem (
https://github.com/DonnchaC/onionbalance/tree/develop/onionbalance) and I
am not qualified to say what, if any, additional v3 Stem features will be
useful or outstanding to support the descriptor-blending that is needed for
loadbalanced configurations.

But OnionBalance for v3 will certainly be necessary. :-)

-a

-- 
http://dropsafe.crypticide.com/aboutalecm
___
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?

[Alec Muffett]

It's not just about getting the protocol stack right, but also the
ancillary software environment; people keep asking me for "V3 support in
EOTK" and my stock response is this:

 BEGIN 
OnionBalance requires STEM support for V3, before it can be updated
(possibly a substantial rewrite will be needed) to support the new format
onions. It's not only a matter of "longer addresses" but also a matter of
cross-signing the descriptors to support new-style cryptography, so in fact
it might be safest to create a new, separate OnionBalance for V3.

So: STEM needs updating and testing for V3, and then OnionBalance needs to
support the new STEM library and encryption. Then (for me) EOTK needs to
support the new OnionBalance.

I am not expecting a solution to ship until 2019, earliest.
 END 

...and that's even without refactoring the other bits of EOTK to address
the changes when STEMv3 lands.


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"

...and it's already in the codebase at
https://github.com/alecmuffett/eotk/blob/master/templates.d/nginx.conf.txt#L299

- alec :-)

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Error-Correcting Onions with Bech32

[Alec Muffett]

On 31 December 2017 at 02:46, nullius  wrote:

> For the foregoing reasons, I will propose that subdomain data, if any, be
> kept separate from the Bech32 coding.  It may be either kept in a separate
> string, or somehow affixed with a special delimiter either before or after
> the Bech32 representation of the onion.  Off-the-cuff, which of these looks
> best to you?
>
> www:onion19qzypww2zw3ykkkglr4tu9
>
> onion19qzypww2zw3ykkkglr4tu9:www
>
> another-level.www:onion19qzypww2zw3ykkkglr4tu9
>
> (My choice of a delimiter here may be wrong, if we want for the browser’s
> address bar to translate it.  I should think more about this.)
>


I need to think about this more, and after coffee, but my first concerns
would be:

1) that having multiple representations of a site's onion address is likely
to break many/most sites, because of Host/Origin headers being complicated
enough already.

2) anything involving colons in any position ("https://
onion19qzypww2zw3ykkkglr4tu9:www/") is likely to break both
client-side-web-browsers and server-side-CMS-software unless they are
specially re-engineered for Tor, which is likely to inhibit use *of* Tor;
colons are a port-number separator in URLs, unless they come as part of an
IPv6 address in [square brackets].


My general sense is that:

a) if Onion addresses suddenly stop looking very-similar-to DNS addresses,
Tor risks returning to a world where special expertise is necessary to
build software for it, thereby harming growth/adoption

b) if Onion addresses have 2+ forms, one like the current (www.
4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion) and the
other being apparently more human-usable because it contains a CRC, the one
which allows access to websites will win.


My expectation to date has been that the problem with "
4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad" is that that
there is no place for the eyeball to rest when typing it in; as such I've
presumed that a canonical form, defined by Tor, would be something like:

https://www.
4acth47i-6kxnvkew-tm6q7ib2-s3ufpo5-sqbsnzjp-bi7utij-cltosqem-ad.onion/

 ...being N groups of M characters (where N and M can be argued, feel
free...) and where any unused characters within the 63-character
DNS-compliant budget can be used to implement a credit-card-like running
checksum or CRC, for quick client-side checks; eg: the URL bar can identify
that you are typing in an Onion address and leave it red-or-grey until you
type something which satisfies the checksum, before flinging it at
tor-daemon for attempted resolution.

Or, indeed, you could leave out the hyphens and do the same; the Prop224
Onion address is 59 characters, leaving a budget of 63-59==4 characters or
20 bits; we could put these at the end, in the space marked "":

  https://www4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad@
@@@.onion/

and use those 20 bits to implement 5x 4-bit checksums over 12-character
chunks:

   https://{www
4acth47i6}{kxnvkewtm6q7}{ib2s3ufpo5sq}{bsnzjpbi7uti}{jcltosqemad@}@@@.onion/

...so that any UX component which wants to help the user can highlight (in
red? or bold?) where the problem is, picking out a chunk of 12 characters
which contain the typo:

   https://www4acth47i6kxnvkewtm6q7*ib2s3ujpo5sq*
bsnzjpbi7utijcltosqemadwxyz.onion/
  -

Spot the errant 'j'.

The advantage of a system like this is that it's not perfect, but a typo
mostly has to happen twice and be quite fortunate to go undetected.

Of course it's not perfect, but nothing will be, and clever selection of
checksum and encoding will result in something which is still DNS- and
Browser-compliant.

-a



-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Error-Correcting Onions with Bech32

[Alec Muffett]

Thanks! That's very interesting!  TIL :-)

What would you propose to do with subdomains, like
www.facebookcorewwwi.onion? Or is that outside the scope of your proposal?

- alec

On 31 Dec 2017 00:53, "nullius"  wrote:

> # Synopsis
>
> The Bech32 standard for error-correcting base32 strings was developed
> explicitly for relative ease and reliability in human communication of
> pseudorandom bitstrings.  I invite discussion of specifying Bech32 as an
> alternative means for representing RFC 7686 .onion domain names.  Should
> the response hereto be positive, then I will offer a formal proposal.
>
> I have written and released a tool which automatically recognizes and
> encodes/decodes .onion addresses in Bech32.  To complement whatever I here
> say, please get a hands-on feel for Bech32 .onions:
>
> https://github.com/nym-zone/bech32
>
> Manpage (yes, a real manpage!):
> https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt
>
> # Background: About Bech32
>
> Bech32 is specified by the Bitcoin BIP 173 standard,[1] co-authored by
> Pieter Wuille and Greg Maxwell.  According to Mr. Maxwell, “Bech32 is
> designed for human use and basically nothing else”; the underlying research
> and development process involved extensive testing with human users,
> analysis of NIST visual confusability data, and the integration of a BCH
> code with strong error correction and detection properties.
>
> [1] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
>
> I refer to BIP 173 for further explanation of Bech32’s design properties,
> its rationales, and the limits of its error handling.
>
> A specific application of Bech32 is Bitcoin’s new address format for the
> future, which I call “Bravo Charlie Addresses” after the letters “bc”
> specified for Bitcoin addresses in the standard’s “human-readable part”
> (HRP).  However, the standard was written to permit general use in other
> applications.
>
> Having in hand a standard explicitly designed to ease the pain which
> wetware suffers when it comes into contact with pseudorandom gibberish, the
> cypherpunk in me is overjoyed at the potentials.  One is a concept which I
> call “PGP Descriptors”, which I am currently working to specify with a few
> extra features and nuances.  And of course, I think of .onions!
>
> # Bech32 for .onion
>
> I hereby nominate “onion” as the logical HRP for RFC 7686 .onion
> special-use domain names.
>
> Here is Bech32 .onion by example, using my bech32 tool with its built-in
> .onion support to encode and decode the name for the Tor Project’s .onion
> equivalent of its “www” site:
>
> ```
> $ bech32 -e expyuzz4wqqyqhjn.onion
> onion1yh0c5eeuksscs8fdyd8406
> $ bech32 -d onion1yh0c5eeuksscs8fdyd8406
> expyuzz4wqqyqhjn.onion
> ```
>
> The string is longer, because it contains 6 base32 characters’ worth of
> error-correcting code.  N.b. also, the foregoing should work just fine for
> v3 onions (formerly prop-224).
>
> Imagine the impact on users who have a practical need to transmit a .onion
> address by verbal communication, or via a handwritten note.  Now they can
> get some help with errors, instead of wondering why they can’t connect to a
> nonexistent .onion site.
>
> The standard enjoins applications against autocorrecting Bitcoin
> addresses, so as to prevent even the slightest possibility of causing funds
> loss by being too “helpful”.  But in applications where it would be safe to
> do so, Bech32 can indeed correct small errors (as well as reliably
> detecting much worse errors).  I suggest that such automatic correction
> would be suitable for .onion addresses.
>
> Bech32 co-author Dr. Wuille (sipa) has published Javascript reference
> code, plus a Javascript error-correction demo, under an MIT license.
> Perhaps this may be easily adapted into Torbutton, for automagic decoding
> of Bech32 “onion1” to .onion domains in the Tor Browser address bar.  The
> code is in the same repository whence I copied the Bech32 reference C code
> I use internally in my tool:
>
> https://github.com/sipa/bech32
>
> # Conclusion—or, to be continued...
>
> An alternative representational format with error-correcting codes will
> make .onion addresses more human-friendly.  I look forward to the day when
> “onion1” addresses can be passed by handwritten notes, vocalized with a
> radio alphabet, stuffed into QR codes, scrawled on parchments placed in
> bottles tossed to sea, rocketed into space, and then conveniently
> transformed with appropriate corrections into the DNS-style .onion format
> specified by RFC 7686.
>
> Here’s to the alternative Onion format of the future!
>
> --
> null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to hide.’
> No!  Because I do nothing wrong, I have nothing to show.” — 

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Alec Muffett]

I think it's important to point out that a Tor client is never
guaranteed to hold a *definitive* consensus.


That's why I say "(mostly) definitive" in my text - my feeling is that a
locally-held copy of the consensus to be queried is going to be on average
of far higher quality, completeness, and non-stagnancy than something that
one tries to scrape out of Onionoo every 15 minutes.

True "definitiveness" can wait. A solution which does not require treading
beyond the local area network for a "good enough" result, is a sufficient
90+% solution :-)


If we were to create "the definitive exit node oracle" we would need a
Tor client that polls the dirauths the second a new consensus comes out,


So let's not do that, then.


Furthermore, you said that enterprises might be spooked out by
tor-specific "special" HTTP headers,


Yes.


but now we are discussing weird tor
modules that communicate with the Tor daemon to decide whether to
redirect clients, so it seems to me like an equally "special" Tor setup
for sysadmins.


I can see how you would think that, and I would kind-of agree, but at least
this would be local and cheap.  Perhaps instead of a magic protocol, it
should be a REST API that's embedded in the local Tor daemon?  That would
be a really, REALLY common pattern for an enterprise to query.

How about that?

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

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Alec Muffett]

On 15 Nov 2017 12:18, "Iain R. Learmonth"  wrote:

Is this not what TorDNSEL does?
https://www.torproject.org/projects/tordnsel.html.en


Hi Iain!

That certainly sounds like it will give you the answer! But although it
would give the right kind of answer, it is not what I am asking for.

At the scale of websites like Facebook or the New York Times, a timely
response is required for the purposes of rendering a page. The benefits of
solving the problem at "enterprise" scale then trickle down to
implementations of all sizes.

Speaking as a programmer, it would be delightfully easy to make a DNS query
and wait for a response to give you an answer... but then you have to send
the query, wait for propagation, wait for a result, trust the result, debug
cached versions of the results, leak the fact that all these lookups are
going on, and so forth.

This all adds adds up to latency and cost, as well as leaking metadata of
your lookups; plus your local DNS administrator will hate you (cf: doing
name resolution for every webpage fetch for writing Apache logs, is frowned
upon.  Better to log the raw IP address and resolve it later if you need.

On the other hand: if you are running a local Tor daemon, a copy of the
entire consensus is held locally and is (basically) definitive.  You query
it with near zero lookup latency, you get an instant response with no
practical lag behind "real time", plus there are no men in the middle, and
there is no unwanted metadata leakage.

If the Tor daemon is on the local machine, then the lookup cost is
near-zero, and - hey! - you are encouraging more people to run more tor
daemons, which (as above) has to be a good thing.

So: the results are very close to what TorDNSEL provides, but what I seek
is something with different and better latency, security, reliability and
privacy qualities than TorDNSEL offers.

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

Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[Alec Muffett]

Apologies, I am waiting for a train and don't have much bandwidth, so I
will be brief:

1) There is no point in issuing  to anyone unless
they are accessing  via an exit node.

2) It's inefficient to issue the header upon every web access by every
person in the world; when the header is only relevant to
1-in-a-few-thousand users, you will be imposing extra bandwidth cost upon
the remaining 99.99...% -- which is unfair to them

3) Therefore: the header should only be issued to people arriving via an
exit node.  The means of achieving this are

a) Location

b) Bending Alt-Svc to fit and breaking web standards

c) Creating an entirely new header

4) Location already works and does the right thing.  Privacy International
already use this and issue it to people who connect to their .ORG site from
an Exit Node.

5) Bending Alt-Svc to fit, is pointless, because Location already works

6) Creating a new header? Given (4) and (5) above, the only potential
material benefit of it that I can see would be to "promote Tor branding" -
and (subjective opinion) this would actually harm the cause of Tor at all
because it is *special*.

6 Rationale) The majority the "Dark Net" shade which had been thrown at Tor
over the past 10 years has pivoted upon "needing special software to
access", and creating (pardon me) a "special" header to onionify a fetch
seems to be promoting the weirdness of Tor, again.

The required goal of redirection to the corresponding Onion site does not
require anything more than a redirect, and - pardon me - but there are
already 4x different kinds of redirects that are supported by the Location
header (301, 302, 307, 308) with useful semantics. Why reinvent 4 wheels
specially for Tor?

7) Story: when I was implementing the Facebook onion, I built infra to
support such (eventual) redirection and/or exit-node-usage tracking. Hit "
facebook.com/si/proxy/" from Tor/NonTor to see it in action. The most
challenging thing for me was to get a reliable and cheap way to look-up,
locally, quickly, cheaply and reliably, whether a given IP address
corresponded to an exit node. The closest that I could get to that idea was
to scrape Onionoo every so often and to cache the results into a
distributed, almost-memcache-like table for the entire site. ie: squillions
of machines. This mechanism suffers from all the obvious flaws, notably
Onionoo crashes and/or "lag" behind the state of the consensus.

8) So, to pass concrete advice on the basis of experience: rather than
pursue novel headers and reinvent a bunch of established, widely-understood
web redirection technologies, I would ask that Tor focus its efforts
instead upon providing a service - perhaps a listener service embedded in
little-t tor as an enable-able service akin to SOCKSListener - which can
accept a request from , receive an newline-terminated IP
address, and return a set of flags associated with that IP (exit node,
relay, whatever) - or "none" where the IP is not part of the tor network.
Riff on this protocol as you see fit.

This would mean more people running more tor daemons in more datacentres
(and possibly configuring some of them as relays) - using this lookup
service to establish quickly whether $CLIENT_ADDR is an exit node or not,
and whether it should be issued "308 Permanent Redirect With Same Method"

I think this is a better goal for Tor to be pursuing.  What do you think?

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

Re: [tor-dev] User perception of onion service discovery

[Alec Muffett]

On 14 October 2017 at 19:43, dawuud  wrote:
>
> Plaintext communications intermediaries like tor2web violate the end
> to end principle and the principle of least authority. If we as the
> Tor community are committed to human rights then it follows we would
> abolish terrible things like tor2web or at least frown upon it's use.
>


I would recommend continuing to enable/support Tor2Web, or at least not
moving to make such a solution inoperable.


Dawuud is absolutely right re: violation of E2E* and a bunch of other
criticisms also apply; however I have three observations on this topic:

1) Someone invented Tor2web, therefore someone else is likely to want to
reimplement it; ideas tend to persist in this way

2) (as observed above) Google *do* crawl onion sites via "onion.to", which
is a fun surprise for people who insist that "The Dark Web Is Not Indexed
And Is Therefore Spooky"

3) Making such a move to block Tor2web-like sites might engender false
trust amongst the people who set up Onion sites: "It's Okay, Google Can't
Get At Us"


I would recommend investing more effort in Tor2web/similar, because having
a permeable barrier between IP-Space and OnionSpace appears useful.

At very most I might propose that:

a) OnionSites become aware of the X-Tor2web header which (from legit T2W
instances, at least) permits the OnionSite operator to block or redirect
the user to use a "proper" Onion network connection

b) That TheTorProject consider indexing known Tor2web sites and publish
them, perhaps adding a feature to optionally block them from TorBrowser
access**, thereby to prevent stupid intra-Tor deanonymisation loops

- a


*although speaking as a geek I believe that re-engineering T2W to support
SSL via SNI-Sniffing would address this, it would be a gross and pointless
hack, complicated still further by certificate issuance, and all reasonable
use cases for which would be better addressed by running a local copy of
Tor.

**the hardcore alternative of blocking them from being accessed by exit
nodes causing a likely-intolerable argument.


-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] User perception of the prop224 domain format

[Alec Muffett]

On 27 September 2017 at 22:25, Ben Laurie  wrote:

> Your survey is obviously massively biased towards users of Tor. It
> would be really interesting to know what non-users think.


 Yes and no; I can totally see that from a user-experience perspective, it
would be exciting research to rock up to someone and say:

"Here's a really long URL, how does it make you feel?"

…and (at least) in this matter, Prop224 Onion addresses are subjectively
less intimidating than:

https://[2001:0db8:85a3:::8a2e:0370:7334]/foo.html

…even though both of them are representations of Layer-3/similar
machine-readable addresses*

*However*, there is such a thing as "inviting people to beat you up in such
a way as to draw media criticism without plausible likelihood for
constructive input", and I feel that this would be onesuch.

Experiential evidence:

1) the number of people who've told me in-past that Email addresses are
unusably unmemorable, except somehow 30..40 years later we are still using
them, and have developed coping strategies, eg: address books.

2) the number of people who've told me in-past that IPv4 addresses are
unusably unmemorable, except for 8.8.8.8 and 192.168.1.1 which somehow are
enough for people to bootstrap access to the rest of the internet, and use
various coping strategies (eg: DNS, bookmarks)

3) the number of people who've told me in-past that Old-Style Onion
addresses are unusably unmemorable, until (as mentioned above) Facebook and
a few other good ones got mined, and people started taking Onion networking
mildly seriously as a means of more-secure enterprise communication… Oh,
and bookmarks as a coping strategy.

4) phone numbers. unusably unmemorable. coping strategies: in-phone address
books + address-book synchronisation. etc etc etc.


So: can we do better with Onion UX? Certainly.

Should we research improvements to user experience? Absolutely.

Should Tor invite opinionated people to come piss all over its equivalent
of https://[2001:0db8:85a3:::8a2e:0370:7334]/foo.html? Probably
not. Just my opinion. I don't feel it would benefit anyone except (a)
haters, and (b) academics who research only "what doesn't work" because
researching "what /does/ work" is beyond the scope of their funding.

 -a

* explanatory thread:
https://twitter.com/AlecMuffett/status/802161730591793152

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Doesn't hidden services break RFC 3986?

[Alec Muffett]

Also: just because it's HTTP/S running over a different network stack,
doesn't make it a new scheme.

Just because your dinner arrives on a different plate doesn't mean the
recipe has changed. :-)

On 14 Aug 2017 8:53 am, "Andreas Krey"  wrote:

> On Sun, 13 Aug 2017 17:06:20 +, Ryan Carboni wrote:
> > https://tools.ietf.org/html/rfc3986#section-3
> > By placing the scheme within the authority as a tld while using the same
> > authority as the HTTP specification, this probably breaks RFC 3986 and
> > maybe others.
>
> RFC7686 deals with that.
>
> Andreas
>
> --
> "Totally trivial. Famous last words."
> From: Linus Torvalds 
> Date: Fri, 22 Jan 2010 07:29:21 -0800
> ___
> 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] Comments on proposal 279 (Name API)

[Alec Muffett]

On 8 April 2017 at 03:23, Yawning Angel <yawn...@schwanenlied.me> wrote:

> On Fri, 7 Apr 2017 11:44:03 +0100
> Alec Muffett <alec.muff...@gmail.com> 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 c

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

[Alec Muffett]

>
> > I suggest that we require all address suffixes to end with .onion;
> > other TLDs are not reserved like .onion is, and maybe we shouldn't
> > squat any we haven't squatted already.
>
> FWIW it's not at all clear to me that this is a concern that IETF or
> ICANN will care about.


Hi.

My name is Alec.

I fought that battle.  I still bear the scars.

Nick is right. Jeremy is not right.

ICANN and IETF and (nobody mentioned) CA/B-Forum members will violently
attack Tor as being weird if it blithely ignores the rest of DNS space.

Also, the concept of the ".alt" domain has been discussed for a long time,
and last I saw will continue to be discussed for a long time.

For Tor to not shoot itself in the head and foot simultaneously, it must:

   1. stick to ".onion" as a top level domain
   2. not tread on the rest of the namespace in any way whatsoever
   3. be able to make credible arguments that whatever exists under
   ".onion" is somehow cryptographic, attested by certs, blockchains, and shit
   like that, rather than "authorities" which would otherwise make the DNSOP
   workgroup feel pissy

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
   - declare a registry of short, valid labels, in the second-from-right
   position in the name
   - reserve "tor" and "name" in that registry (ie: *.tor.onion,
   *.name.onion)
   - park the entire issue for 12 months

Because some geeks are nerds there will doubtless be arguments about the
creation of a registry, about forking the codebase, about "I am taking my
ball and going home because this is oppression!" and a bunch of other stuff.

Hence "parking" the issue because this is all meaningless until prop224
addresses ship, and there should be plenty of time in the next 12 months
for people to think about how to fill the usability space with $PET_IDEA,
and to my mind the changeover period between 80-bit and 256-bit addresses
should be long enough that nobody need fret about it right now.

The Prop224 migration will be doubtless faster than the IPv6 migration, but
anyone who says the changeover period should be less than 2 years is trying
to kill Tor adoption.

-a

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 5 April 2017 at 15:11, Ian Goldberg  wrote:

> I believe the danger Alec was wanting to avoid was that someone (not the
> onion service owner) could take an existing onion address, bump the
> version number (which wouldn't change the vanity beginning of the
> address), and upload the very same descriptor to the resulting blinded
> address (under the new version number).  Then the modified address would
> work just like the original.
>


In a nutshell, yes.

I've been having a discussion with Taylor Campbell off-list, and I wrote:

   - *… let me try something on you: *
   -
*The year is 2019.  *
   -
*What would _you_ do  *
   -
*in order to surface to the user  *
   -
*that the onion address in front of them,  *
   -
*one with a given public key which they've previously used and trusted
   before *
   -
*such that the leftmost 32 bytes, base32 encoded, are familiar to them,  *
   -
*is actually a downgraded version-2 format of address *
   -
*against which a bug is being exploited by (say) the FBI *
   -
*rather than the more secure version-3 form which they were expecting and
   had previously used, *
   -
*when all of the information pertinent to versions and checksums is at the
   right-hand-end of the encoded address? *
   - *This is basically where I am coming from.*
   -
*My thinking: Make it brittle. Mix the version (etc) into the represented
   form so that if one messes with a single bit, one perceptibly impacts the
   entire string representation of the onion address. How would you attack
   this? *


...and also:


> *do we want to be teaching users that:*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5c5bc5, and*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5d5bc5**...are
> actually the same thing, but if and only if they differ in the N-5'th
> character?*



...and:


> *… up front I'll just say that my perspective of this class of threat
> comes from observations like *
> *a) people are creative, and if you give them malleability they will use
> it to create onion addresses including embedded "poop-emoji" and the like.*
> *b) people generalise, so that having learned that $SOME_CHARACTER in an
> onion address is malleable, they will assume that most/all of them are and
> subsequently fall for phishing attacks.**c) people are, as a group, given
> the entire Tor prop224 ecosystem, infinitely more creative than I can be at
> finding ways to exploit it, therefore it makes sense to screw down the
> crypto to present as small an attack surface as possible.*



...and:


> *An old programmer maxim is that one should provide for Zero, One, or an
> Infinite number of any resource.  *
> *Since we do not desire an infinite number of representations of an onion
> address (per Roger) - and zero would not be useful, we should shoot for
> one, and only one.**Not a cryptographic argument, but I think it's a
> human one.  :-)*


There's a lot more, but I don't want to bury folk with a huge multi-message
e-mail exchange; plus there is a lot of useful context "up-thread".  :-)



> As mentioned elsewhere in the thread, this is solved if that descriptor
> contains (under the signature by the "master" onion key) the actual
> onion address you were expected to use to get there.  Does it?  If so,
> I think we don't have to worry about this problem at all.


I hope it does.  That sounds very much like what I expect to see in other
network stacks.  :-)

-a

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

Following the Layer-2 Addressing analogy means that Ian, here:


> If the daily descriptor uploaded to the point
>> Hash(onionaddr, dailyrand) contained Hash(onionaddr, dailyrand) *in* it
>> (and is signed by the master onion privkey, of course), then tor
>> could/should check that it reached that location through the "right"
>> onion address.
>
>
…has essentially just invented what Solaris (for one) calls "IP Strict
Destination Multihoming":

  http://www.informit.com/articles/article.aspx?p=101138=4

-a :-)


-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 3 April 2017 at 16:59, Ian Goldberg  wrote:

> How about this, though: I know that Tor doesn't want to be in the business
> > of site reputation, but what if (eg) Protonmail offers a Onion "Safe
> > Browsing" extension some day, of known-bad Onions for malware reasons?


> That's a quite good motivating example, thanks!


#Yay; I'm also thinking of other plugins (in the cleartext world,
HTTPSEverywhere is the best example) which provide value to the user by
mechanically mutating URIs which match some canonical DNS domain name;
because Onion addresses are more like Layer-2 addresses*, development of
similar plugins benefits greatly from enforced "canonicality" (sp?) than is
necessary for equally-functional DNS equivalents; there is no means to
"group" three disparate Onion addresses together just-because they are all
owned by (say: Facebook), and if each address has 8 possible
representations then that's 24 rules to match against...


> There's quite a gulf between stripping hyphens from a candidate onion
> > address and doing strcmp(), versus either drilling into the candidate
> > address to compute the alternative forms to check against the blacklist,
> or
> > even requiring the blacklist to be 8x larger?
>
> Yes, that's true.  I'm definitely in favour of the "multiply by L (the
> order of the group) and check that you get the identity element; error
> with 'malformed address' if you don't" to get rid of the torsion point
> problem.
>

I heard that and AMS and it sounds a fabulous idea, although I am still too
much of an EC noob to appreciate it fully. :-)


If the daily descriptor uploaded to the point
> Hash(onionaddr, dailyrand) contained Hash(onionaddr, dailyrand) *in* it
> (and is signed by the master onion privkey, of course), then tor
> could/should check that it reached that location through the "right"
> onion address.
>

That sounds great, and I think it sounds an appropriate response, but again
I am a Prop224 and EC noob. :-)

I would like, for two paragraph, to go entirely off-piste and ask a
possibly irrelevant and probably wrong-headed question:

/* BEGIN PROBABLY WRONG SECTION */
I view Onions as Layer-2 addresses, and one popular attack on Ethernet
Layer 2 is ARP-spoofing.  Imagine $STATE_ACTOR exfiltrates the private key
material from $ONIONSITE and wants to silently and partially MITM the
existing site without wholesale owning or tampering with it. Can they make
any benefit from multiple ("hardware MAC-address") keys colliding to one
address? Is there any greater benefit to $STATE_ACTOR from this than (say)
publishing lots of fake/extra introduction points for $ONIONSITE and using
those to interpose themselves into communications?
/* END PROBABLY WRONG SECTION */


I'm afraid the details of what's in that daily descriptor are not in my
> brain at the moment.  Does it contain its own (daily blinded) name under
> the signature?
>

  George?

  -a

--
* Layer-2 analogy: https://twitter.com/AlecMuffett/status/802161730591793152


-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 3 Apr 2017 3:48 p.m., "Ian Goldberg"  wrote:

The other thing to remember is that didn't we already say that

facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion

and

face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion

will mean the same thing?  So we're already past the "one (st)ring to
rule them all" point?


That's a great point, and I'm definitely interested and in favour of
readability.

How about this, though: I know that Tor doesn't want to be in the business
of site reputation, but what if (eg) Protonmail offers a Onion "Safe
Browsing" extension some day, of known-bad Onions for malware reasons?

There's quite a gulf between stripping hyphens from a candidate onion
address and doing strcmp(), versus either drilling into the candidate
address to compute the alternative forms to check against the blacklist, or
even requiring the blacklist to be 8x larger?

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

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 3 April 2017 at 13:04, George Kadianakis  wrote:

> I'm calling it weird because I'm not sure how an
> attacker can profit from being able to provide two addresses that
> correspond to the same key, but I can probably come up with a few
> scenarios if I think about it.


Hi George!

I'll agree it's a weird edge case :-)

I think the reason my spider-sense is tingling is because years of cleaning
up after intrusions has taught me that sysadmins and human beings are very
bad at non-canonical address formats, especially where they combine them
with either blacklisting, or else case-statements-with-default-conditions.

If one creates scope for saying "the address is .onion but you can
actually use .onion or .onion which are equivalent" - then
someone will somehow leverage that either a) for hackery, or b) for social
engineering.

Compare:

* http://01770001
* http://2130706433
* http://0177.0.0.1  <- this one tends to surprise people
* http://127.0.0.1

…and the sort of fun shenanigans that can be done with those "equivalent
forms"

People who've been trained not to type [X] into their browser, might be
convinced to type [X']

It's a lot easier for people to cope with there being one-and-only-one
viable form for any given hostname or address-representation.

-a

 --
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

>
> We could leave the version field outside the AONT, though, but commit to
> changing the paramaters of the AONT (in particular, the domain
> separation constant?) if we change the version number, so that an
> adversary changing the version number to "2" would just cause the client
> to throw an error (before version 2 exists) or be an invalid address
> (after version 2 exists)?


To add an aside from a discussion with Teor: the entire "version" field
could be reduced to a single - probably "zero" - bit, in a manner perhaps
similar to the distinctions between Class-A, Class-B, Class-C... addresses
in old IPv4.

Thus: if the first bit in the address is zero, then there is no version,
and we are at version 0 of the format

If the first bit is one, we are using v1+ of the format and all bets are
off, except that the obvious thing then to do is count the number of 1-bits
(up to some limit) and declare that to be version number.  Once we're up to
3 or 4 or 7 or 8 one-bits, then shift version encoding totally.

Teor will correct me if I misquote him, but the advantage here was:

a) the version number is 1 bit, ie: small, for the forseeable / if we get
it right

b) in pursuit of smallness, we could maybe dump the hash in favour of a
AONT + eyeballs, which would give back a bunch of extra bits

result: shorter addresses, happier users.

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

Hi,

So: a bunch of us were discussing Prop224 Onion addresses, and their
UX-malleability.

Specifically: that there are small bit fields in the current Prop224 Onion
Address schema (eg: version, and other future structure?) which can be
tweaked or amended without otherwise changing the functionality of the
address, or without much changing what the user sees in the (say) browser
address bar.

This is a point of significant concern because of issues like phishing and
passing-off - by analogy: t0rpr0ject.0rg versus torproject.org  - and other
games that can be played with a prop224 address now, or in future, to game
user experience.

We discussed the existing "hash the public key before base-32 encoding"
approach, but hashing breaks the prop224 key blinding.

Ian Goldberg - thank you Ian - offered this attractive solution: apply a
*reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion
Address, prior to Base32 Encoding.

This way, even a single-bit mutation of (say) version number will have a
"diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and
being reversible so as not to impact the rest of Prop224.

The result would be onion addresses which are less "tamperable" / more
deterministic, that closer to one-and-only-one published onion address will
correspond to an onion endpoint.

What does the panel think?

- alec

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special handling of .onion domains in Chrome/Firefox (post-IETF-standarization)

[Alec Muffett]

> On Nov 2, 2015, at 20:39, Paul Syverson  wrote:
> 
> On Mon, Nov 02, 2015 at 09:05:26PM +0200, George Kadianakis wrote:
>> Hello,
>> 
>> as you might know, the IETF recently decided to formally recognize .onion 
>> names
>> as special-use domain names [0].
>> 
>> This means that normal browsers like Chrome and Firefox can now
>> handle onion domains in a special manner since they know that they
>> only correspond to Tor.
>> 
>> How would we like those browsers to treat onions?
>> 
>> For starters, those browsers should refuse to connect to onion
>> domains entirely.  Onions don't work on normal browsers anyway, and
>> also this will reduce the onion leakage through the DNS system [1].
> 
> Well, maybe not "entirely". Cf. below.



Tangential aside: Chrome currently has a bug open in that it does not yet 
support onion certificates:

https://code.google.com/p/chromium/issues/detail?id=483614 


The Onion RFC lays a burden on DNS to NXDOMAIN onion lookups.

It says nothing about having browsers block them.

Perhaps the better thing for Tor adoption is - privacy purism enforced by TBB 
aside - to enable adoption.

Allow (encourage?) non-TBB browsers to be capable to using Onions.

Roger, after all, stood up movingly at the Aaron Swartz memorial and spoke of 
letting people pick the security that _they_ wanted, when connecting to a site.

This would, I feel, accord with that position.

- alec


ps:

> It might be a better idea to point them to tor2web. For one thing
> browser providers will be happier with a display that doesn't directly
> tell people they need a different browser to get to an intended
> address.


Pointing people at tor2web would break SSL, but see this thread, which is a 
side-show to the larger "how can we get personal onion addresses" discussion: 
https://twitter.com/AlecMuffett/status/658440124624183296 



> The display could say something like:
> 
>  Oops, seems like you attempted to visit an onion address, a
>  specialized address that provides additional security for
>  connections to it. The site can be reached via proxy at
>  [tor2web-link-to-relevant-onionsite]. To obtain the intended
>  security for access to such sites, follow   "[link-to-page-w-brief-simple-explanation-n-prominent-link-to-download-TBB]">
>  these few simple steps .
> 
> No doubt some wordsmithing could make this better in various respects
> (amongst them, shorter).



Phishing-potential in such dialogues, here?

-a


> 
>> 
>> 
>> What else could we do here? And is there anyone who can lobby for the right
>> behavior? :)
>> 
>> Of course, we all know that that inevitably those browsers will need
>> to bundle Tor, if they want to visit the actually secure onion
>> Internet. But let's give them a bit more time till they realize this
>> :)
> 
> I think something like the above improves the transition path, helping
> the world along to better security instead of just waiting for the
> world to catch up. (And in any case, perhaps at least a few more
> months work would better prepare us for the resulting attention.)
> 
> aloha,
> Paul
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Changing Rendezvous Single Onion Service at Runtime

[Alec Muffett]

> On Nov 6, 2015, at 4:16 PM, teor  wrote:
> Hi all,

Hiya!

> Is there any reason an onion service would want to temporarily switch from 
> 1-hop to 3-hop paths?
> Is it ok if we force operators to restart the tor instance when onion service 
> path lengths change?

Well - as a user of RSOS, given the current state of the tor codebase, I feel 
it’s entirely reasonable that having a daemon need to cold-start in order to 
use oddball and privacy-impacting functionality be enabled.

By comparison: Tor2web requires being compiled-in before you can futz with 
connection configurations, and bans attempts to simultaneously set up 
connections in T2W and “normal” mode, so RSOS by comparison appears 
user-friendly. :-)

- alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Alternate Single Onion Service Designs

[Alec Muffett]

> On Nov 6, 2015, at 4:56 PM, teor  wrote:
> Do we need both single onion services (Proposal 252) and rendezvous single 
> onion services?

I would say they are both desirable, and that we could/should have both.

RSOS is great for adoption, the rendezvous step enables NAT-punching and yet 
lowers latency.

The NAT-punching is particularly desirable where - like in our configuration - 
the tor daemon resides in a DMZ enclave without inbound connectivity.

See diagram at: https://twitter.com/dcuthbert/status/573197027242315776/photo/1

Source: https://storify.com/AlecMuffett/tor-tips

RSOS thereby also offers a easy, nearly-no-rearchitecture-required route to 
enterprise deployment.

Also RSOS enables OnionBalance, and other performance hacks such as those 
proposed by Tom van der Woerdt 
(https://lists.torproject.org/pipermail/tor-dev/2015-October/009618.html) all 
without requiring broad changes to deployed Tor daemons

SOS by comparison sounds best where pure performance matters, but I am not sure 
how the other scaling solutions will fit into it; but pure performance matters 
a lot, so overall I think I’d like to see both.

My plans for Onion scaling are approximately as follows:

1) Remove unnecessary privacy hops / deploy RSOS (in progress)

2) OnionBalance: Merge introduction points (IPs) from multiple daemons into one 
descriptor (possible issue: there is a hardcoded limit of 3x IPs?)

3) Steven Murdoch / Ceysun Sucu research: Implement distinct OnionBalance 
descriptors at each (6?) point on the HSDir ring

These three solutions in aggregate should lower latency and scale tor daemon 
bandwidth by a range of 18..60x

Then:

4) (Wishlist) implementation of TVDW's handoff of RP callback

...which will resolve any remaining CPU-bandwidth issues.

These plans are subject to change, but seem reasonable so far.

- alec


> I see at least the following scenarios for using these alternate single onion 
> service designs:
> 
> 0. an onion service operator who wants to minimise latency and maximise 
> bandwidth runs a SOS (a RSOS is slower to connect due to the rendezvous 
> protocol)
> 
> 1. an onion service operator runs a SOS for new clients, and an RSOS for old 
> clients (a RSOS is compatible with current clients, a SOS Is not)
> 
> 2. an onion service operator who can’t expose an ORPort runs a RSOS for all 
> clients (there are enclave and NAT configurations where external ports are an 
> issue)
> 
> 3. an onion service operator who wants to use Proposal 255 for load-balancing 
> runs a RSOS, and splits their introduction and rendezvous instances by 
> passing the introduction over the control port (proposal 255 relies on the 
> rendezvous protocol to handoff the rendezvous point connection to another Tor 
> instance)
> 
> 4. an onion service wants low latency and better bandwidth, and doesn't want 
> to wait until the SOS feature is developed and deployed (SOS is a larger 
> feature, and it needs client changes). They'll switch to SOS when it's well 
> supported by installed versions of Tor Browser.
> 
> Given these use cases, I think we could implement both flavours of single 
> onion service. But this splits the onion service anonymity set at least 3 
> ways (and maybe also by some other onion service features). I'm not sure how 
> much of an impact this will have - it does depend on our threat model for 
> each flavour of onion service.
> 
> If we wanted to generate more onion service cover traffic, we could move 
> various automated Tor Browser actions (such as update checks and update 
> downloads) to appropriate flavours of onion service. This would shift load 
> away from exits, and also have address authentication benefits. (Tor Browser 
> wouldn't have to rely on DNS, CA certificates, and SSL for Its updates.)
> 
> The other mitigations I'm aware of are cover traffic and lookalike protocol 
> interactions, but these require significant research and design work.
> 
> We're working on implementing rendezvous single onion services in #17178. I 
> think they're pretty close: we need to do some more testing, and handle some 
> edge cases. RSOS servers work with existing clients, including current Tor 
> Browser releases.
> 
> Single onion services (Proposal 252) is a larger feature, so it's a bit 
> further away. SOS are incompatible  with current clients, so supporting code 
> will need to be deployed in Tor clients (such as Tor Browser) as well as on 
> the onion service itself. After the feature is ready, there will be some lead 
> time before SOS are usable with the majority of deployed Tor clients.
> 
> What do you think?
> Are onion services big enough to safely have multiple flavours?
> Could they get that big if we support enough functionality?
> Or are we better to implement secure, one-size-fits-all defaults, and ask 
> users and operators to sacrifice some performance?
> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com
> PGP 968F094B
> 
> teor 

Re: [tor-dev] Onion Services and NAT Punching

[Alec Muffett]

> On Oct 26, 2015, at 11:34, Alec Muffett <al...@fb.com> wrote:
>> Of course. All the cases where you set up a hidden service
>> exactly because your host is behing a NAT.
>> Like the webcam raspi I'm just booting up.
> 
> We run our tor daemons in a enclave network which can only connect outbound 
> to the Internet, or backwards into infrastructure.

Also, it's probably wise to point out that NAT-punching (and/or SOCKS-punching 
outbound) reduces cost of HS adoption for organisations that don't want to 
rejig their network architecture to permit "yet another listener"; it's an 
attractive proposition to say "it only connects outbound and rendezvouses 
(sic?) in the middle of the tor cloud" #ohThatsOkayThenNoFirewallChanges



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Services and NAT Punching

[Alec Muffett]

> On Oct 1, 2015, at 06:15, Andreas Krey  wrote:
> 
>> Are there any use cases that:
>> * need NAT punching,
>> * don't need service location anonymity, and
>> * would benefit from lower latency?
> 
> Of course. All the cases where you set up a hidden service
> exactly because your host is behing a NAT.
> Like the webcam raspi I'm just booting up.

And like us.  We run our tor daemons in a enclave network which can only 
connect outbound to the Internet, or backwards into infrastructure.

-a



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

[Alec Muffett]

> Let's use your idea of "if one IP fails and TTL expired then re-fetch".
> This could also make it "easier" to identify people connecting to
> Facebook. As your client guard, I see you do the fetch + IP/RP dance (3
> circuits in short period of time where two are killed). I wait 2 hours
> and then kill all circuits passing through me from you. If I can see
> again that distinctive HS pattern (3 circuits), I'll get closer to know
> that you are accessing FB.


Would that not happen if and only if (in the meantime) the server had had a 
server outage impacting the first IP that the client tries reconnecting to?

Odds on, the client entry guard will see no measurable change?

-a

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

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

[Alec Muffett]

i...@tvdw.eu wrote:

> Hi Alec,

Hi Tom! I love your proposal, BTW. :-)

> Most of what you said sounds right, and I agree that caching needs TTLs (not 
> just here, all caches need to have them, always).

Thank you!

> However, you mention that one DC going down could cause a bad experience for 
> users. In most HA/DR setups I've seen there should be enough capacity if 
> something fails, is that not the case for you? Can a single data center not 
> serve all Tor traffic?

It's not the datacentre which worries me - we already know how to deal with 
those - it's the failure-based resource contention for the limited 
introduction-point space that is afforded by a maximum (?) of six descriptors 
each of which cites 10 introduction points.

A cap of 60 IPs is a clear protocol bottleneck which - even with your excellent 
idea - could break a service deployment.

Yes, in the meantime the proper solution is to split the service three ways, or 
even four, but that's administrative burden which less well-resourced 
organisations might struggle with.

Many (most?) will have a primary site and a single failover site, and it seems 
perverse that they could bounce just ONE of those sites and automatically lose 
50% of their Onion capacity for up to 24 hours UNLESS they also take down the 
OTHER site for long enough to invalidate the OnionBalance descriptors.

Such is not the description of a high-availability (HA) service, and it might 
put people off.

> If that is a problem, I would suggest adding more data centers to the pool. 
> That way if one fails, you don't lose half of the capacity, but a third (if 
> N=3) or even a tenth (if N=10).

...but you lose it for 1..24 hours, even if you simply reboot the Tor daemon.

> Anyway, such a thing is probably off-topic. To get back to the point about 
> TTLs, I just want to note that retrying failed nodes until all fail is scary:

I find that worrying, also. I'm not sure what I think about it yet, though.

> what will happen if all ten nodes get a 'rolling restart' throughout the day? 
> Wouldn't you eventually end up with all the traffic on a single node, as it's 
> the only one that hadn't been restarted yet?

Precisely.

> As far as I can see the only thing that can avoid holes like that is a TTL, 
> either hard coded to something like an hour, or just specified in the 
> descriptor. Then, if you do a rolling restart, make sure you don't do it all 
> within one TTL length, but at least two or three depending on capacity.

Concur.


desnac...@riseup.net wrote:

> Please see rend_client_get_random_intro_impl(). Clients will pick a random 
> intro point from the descriptor which seems to be the proper behavior here.

That looks great!

> I can see how a TTL might be useful in high availability scenarios like the 
> one you described. However, it does seem like something with potential 
> security implications (like, set TTL to 1 second for all your descriptors, 
> and now you have your clients keep on making directory circuits to fetch your 
> descs).

Okay, so, how about:

IDEA: if ANY descriptor introduction point connection fails AND the 
descriptor's ttl has been exceeded THEN refetch the descriptor before trying 
again?

It strikes me (though I may be wrong?) that the degenerate case for this would 
be someone with an onion killing their IP in order to force the user to refetch 
a descriptor - which is what I think would happen anyway?

At very least this proposal would add a work factor.

> For this reason I'd be interested to see this specified in a formal Tor 
> proposal (or even as a patch to prop224). It shouldn't be too big! :)

I would hesitate to add it to Prop 224 which strikes me as rather large and 
distant.  I'd love to see this by Christmas :-P


teor2...@gmail.com wrote:

> Do we connect to introduction points in the order they are listed in the 
> descriptor? If so, that's not ideal, there are surely benefits to a random 
> choice (such as load balancing).

Apparently not (re: George) :-)

> That said, we believe that rendezvous points are the bottleneck in the 
> rendezvous protocol, not introduction points.

Currently, and in most current deployments, yes.

> However, if you were to use proposal #255 to split the introduction and 
> rendezvous to separate tor instances, you would then be limited to:
> - 6*10*N tor introduction points, where there are 6 HSDirs, each receiving 10 
> different introduction points from different tor instances, and N failover 
> instances of this infrastructure competing to post descriptors. (Where N = 1, 
> 2, 3.)
> - a virtually unlimited number of tor servers doing the rendezvous and 
> exchanging data (say 1 server per M clients, where M is perhaps 100 or so, 
> but ideally dynamically determined based on load/response time).
> In this scenario, you could potentially overload the introduction points.

Exactly my concern, especially when combined with overlong lifetimes of 
mostly-zombie descriptors.

- alec

[tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

[Alec Muffett]

So I’ve just had a conversation with dgoulet on IRC, which I will reformat and 
subedit here as a conversation regarding OnionBalance and issues in 2.6 and 2.7 
when a recently rebooted HS publishes a fresh descriptor:

[…]

alecm: consider OnionBalance which - being a bunch of daemons on a bunch of 
servers - will be a lot more prone to intermittent failures of 1+ daemons 
yielding a lot of republishing

alecm: we tend to move services around, and daemons will be killed in one place 
and resurrected elsewhere, and then we'll have to bundle up a new descriptor 
and ship it out

dgoulet: hrm so with that new 027 cache behavior, as long as the IP are usable, 
the descriptor will be kept, if they all become unusable, a new descriptor 
fetch is triggered and then those IPs will be tried

alecm: There's a mandatory refresh [of the descriptor] after N minutes?

dgoulet: we'll retry 3 times and after that all HSDir are in timeout for 15 
minutes (I think, I'll have to validate) before retrying any HSDirs

alecm: I wonder if descriptors should publish a recommended TTL - [number of 
seconds to live before refresh]

dgoulet: yeah we have an idea for a "revision-counter" in the descriptor being 
incremented at each new version for the 24 hours period

dgoulet: a TTL could be useful for load balancing though!

alecm: so, here's a scenario: imagine that we run 10 daemons,

alecm: call these daemons: A B C D E F G H I J - they all have random onion 
addresses

alecm: we steal one IP from each daemon, and bundle the 10 stolen IPs together 
to make an onionbalance site descriptor and publish it

alecm: people pull that descriptor, it's quite popular

alecm: we then lose power in a datacentre, which takes out half of our onions - 
say, A through E

alecm: we reboot the datacentre and restart A-E merely 10 minutes later

alecm: everyone who has already loaded our onionbalance site descriptor tests A 
B C D E and finds them all dead, because the old IPs for A-E are invalid

alecm: so they all move to F G H I J - which get overloaded even though (new) A 
B C D E are back up

alecm: and this persists for up to 244, even though the outage was only 10 
minutes

alecm: net result: large chunks of the world (anyone with an old descriptor + 
anyone randomly choosing F-J) have a shitty experience, which is not what 
high-availability is all about :-)

dgoulet: that will be what's going to happen - having a TTL in the desc. would 
help here indeed, I see the issue

dgoulet: TTL would be one thing to add, here we could also add a mechanism for 
a client retrying IPs that failed in the situation where some of the IPs are 
still working, or making client balance themself randomly could be also an idea

dgoulet: definitely there is some content here for tor-dev - I don't have a 
good answer but it should definitely be addressed

alecm: proper random selection of IP would be beneficial for load-balancing; 
not perfect, but in the long run, helpful

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Load Balancing in 2.7 series - incompatible with OnionBalance ?

[Alec Muffett]

typo:

> alecm: and this persists for up to 24h, even though the outage was only 10 
> minutes

Also, I neglected to observe that linear polling of A-E seeking a descriptor 
suggests A will be hammered whilst J is nearly idle.

Some entropy in IP selection would be a good thing.

-a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] IMPT -- Re: Future Onion Addresses and Human Factors

[Alec Muffett]

Aside: in pursuit of helping Jake register “.onion” as a special name” in an 
RFC, I am currently being beaten-up on the IETF discussion mail-list regards 
the potential future length of onion addresses, and that they may possibly 
exceed the bounds of DNS’ maximum label length of 63 characters:

https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html 
https://www.ietf.org/mail-archive/web/ietf/current/msg94332.html

The examples in Proposal 224 are a mere 53 characters long leaving 10 to play 
with for padding-hyphens and possibly checksum characters.

Nick: Is this likely to need to change? Or might there be a need to encode  
315 bits / 63 chars total?

-a

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

 On Aug 10, 2015, at 2:00 PM, Philipp Winter p...@nymity.ch wrote:
 
 Vanity addresses encourage people to only verify the human-readable part
 of an address before clicking on it.  That creates a false sense of
 security, which is already exploited by spoofed onion service addresses
 whose prefix and suffix mimics the original onion address.

That does strike me as a risk.

That said, if an address is completely incapable, even hostile to validation by 
human eyeballs, then what happens is “trust” migrates to using a bunch of tools 
which are forgeable, spoofable, hackable, trojanable.

The resultant risk might be worse for its greater resistance to detection.

-a

ps: for an investigation of what happens when you build a “communities” app 
around “non-human-readable” barcodes and without a discovery mechanism, see 
this article; such innovation gives me great hope for humanity finding 
solutions to apparently high-friction technologies, but it also clearly hampers 
broader inclusiveness, the latter arguably being one of Tor’s most important 
goals:

http://mashable.com/2014/10/24/hacks-facebook-rooms/ 
http://mashable.com/2014/10/24/hacks-facebook-rooms/

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

 On Aug 9, 2015, at 12:36 PM, Ben Laurie b...@links.org wrote:
 
 Can I make my usual radical suggestion? By all means discuss, but once you've 
 finished deciding what you think is best for humans, please actually test 
 your theory. On humans (and that means, not CS students and not Mechanical 
 Turk).

Nicely volunteered, Ben! :-)

/me wonders how much ux-testing the “dotted quad” received…

-a :-)

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

 
 On Aug 8, 2015, at 12:36 PM, Alec Muffett al...@fb.com wrote:
 
 9) appending a credit-card-like “you typed this properly” extra few 
 characters checksum over the length might be helpful (10..15 bits?) - ideally 
 this might help round-up the count of characters to a full field, eg: XXX in 
 this?
 
 
 a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
 


For the avoidance of doubt: I am not proposing use of special-case capital 
letters for checksums.  I merely use capital letters for emphasis.

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

Hi All,

Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion 
moved to Onion-Address Human Factors.

Summary points:

1) it’s all very well to go an mine something like “facebookcorewwwi” as an 
onion address, but 16 characters probably already exceeds human ability for 
easy string comparison.

2) example of the above: there are already “in the field” a bunch of onion 
addresses “passing themselves off” as other onion addresses by means of common 
prefixes.

3) next generation onion addresses will only make this worse

4) from Proposal 244, the next generation addresses will probably be about this 
long:

a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion

5) taking a cue from World War Two cryptography, breaking this into banks of 
five characters which provide the eyeball a point upon which to rest, might 
help:

a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd.onion

6) using underscores would be a pain (tendency to have to use SHIFT to type)

7) using dots would pollute subdomains, and colons would cause parser confusion 
with port numbers in URIs

8) being inconsistent (meaning: “we extract the second label and expunge 
anything which is not a base32 character”, ie: that with-hyphens and 
without-hyphens) may help or hinder, we’re not really sure; it would permit 
mining addresses like:

agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration 
purposes only

…which *looks* great, but might encourage people to skimp on comparing [large 
chunks of] the whole thing and thereby enable point (2) style passing-off.

9) appending a credit-card-like “you typed this properly” extra few characters 
checksum over the length might be helpful (10..15 bits?) - ideally this might 
help round-up the count of characters to a full field, eg: XXX in this?

a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion

10) it might be good to discuss this now, rather than later?

Hence this email, in the hope of kicking off a discussion between people who 
care about human factors.  :-)

- alec


—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

Gah, I am evidently having a bad day with e-mail, so I am going to send a typo 
correction with this and then go do something else instead.

Corrections in caps, below.

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

 On Aug 8, 2015, at 2:14 PM, Alec Muffett al...@fb.com wrote:
 
 Please  let a thousand discovery mechanisms bloom - including peer-to-peer 
 directories and tweeted URLs.
 
 But, what they boil down to, please let *that* be human-readable, too.  The 
 more I THINK about it, the more I like:
 
 a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion
 
 …where the final “xxx” is a 15-bit truncated secure hash of the rest of the 
 original raw address bitstring.
 
 That way people looking to quickly compare addresses can check the first 
 QUINTET, and the last, and sample a few of the inner ones (“…people compare 
 glyphs not words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s 
 like Eeyore in Winnie-The-Pooh, and 0WLGM reminds me of Owls) and be 
 reasonably satisfied and reasonably secure.
 
 And the XXX can be checked by the browser and tell the user that they’ve 
 goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads.
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London

 On Aug 8, 2015, at 2:05 PM, Roger Dingledine a...@mit.edu wrote:
 
 https://urldefense.proofpoint.com/v1/url?u=https://trac.torproject.org/projects/tor/ticket/15622k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0Am=t0VcFezNAZohjkc7dkqY5Pak9%2BW62AHKDN8z436MZq8%3D%0As=50006f472990c7b35011656eec44171543f66f719759d7ee5fd9fdc31fc9b70d
  
 https://urldefense.proofpoint.com/v1/url?u=https://trac.torproject.org/projects/tor/ticket/15622k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0Am=t0VcFezNAZohjkc7dkqY5Pak9%2BW62AHKDN8z436MZq8%3D%0As=50006f472990c7b35011656eec44171543f66f719759d7ee5fd9fdc31fc9b70d


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Alec Muffett]

 On Aug 8, 2015, at 1:44 PM, Paul Syverson paul.syver...@nrl.navy.mil wrote:

Hi Paul!

I think it would be valid to propose a third direction, which is to partially 
give-up arguing about the importance of Zooko’s Triangle and instead make 
attempts to meet human beings and computers somewhere in the middle.

I don’t believe that this direction should preclude development of the other 
two - they might indeed be complementary - but making Onion addresses 
accessible in the ways that an IPv4 “dotted quad” is, or that an IPv6 “::” 
field-pad does, cannot be a bad thing.

There is, as you point out:

 One is to produce human meaningful names in association with onion
 addresses.

…which is akin to the layer that DNS provides atop IP addressing; everyone with 
a domestic DSL router probably has “http://192.168.1.1 http://192.168.1.1/” 
bookmarked somewhere, which is more direct and unambiguous than the 
“http://router http://router/.local” that it may also masquerade as, by 
providing DNS bootstrap through DHCP.

 The other that I am aware of is to bind onion addresses in a human
 meaningful way to existing names, typically registered domain names,

I recall the discussion we had inside Facebook, along the lines of “why don’t 
we register “onion.facebook.com” and issue a redirect, rather than forcing 
people to type this gibberish?” - an argument which was won by the observation 
“we are putting this out for people to have trust, and why should we make them 
trust DNS+redirection when we can instead give them something direct and 
unambiguous

You’ll gather that I like “direct and unambiguous”. :-)

Hence: let there be innovation.

Please  let a thousand discovery mechanisms bloom - including peer-to-peer 
directories and tweeted URLs.

But, what they boil down to, please let *that* be human-readable, too.  The 
more I like about it, the more I like:

a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion

…where the final “xxx” is a 15-bit truncated secure hash of the rest of the 
original raw address bitstring.

That way people looking to quickly compare addresses can check the first octet, 
and the last, and sample a few of the inner ones (“…people compare glyphs not 
words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s like Eeyore 
in Winnie-The-Pooh, and 0WLGM reminds me of Owls) and be reasonably satisfied 
and reasonably secure.

And the XXX can be checked by the browser and tell the user that they’ve 
goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads.

- alec

—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Impending Facebook Onion-Site Certificate Changes

[Alec Muffett]

Hello All!

Details: https://www.facebook.com/facebookcorewwwi/posts/703469239759799 
https://www.facebook.com/facebookcorewwwi/posts/703469239759799

Summary: new EV-style SSL certificate rolls out to facebookcorewwwi.onion next 
week.

- alec
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev