Re: [tor-dev] Proposal: Load-balancing hidden services by splitting introduction from rendezvous

[Tom van der Woerdt]

Op 04/10/15 om 06:46 schreef Tim Wilson-Brown - teor:



On 3 Oct 2015, at 13:34, Tom van der Woerdt > wrote:
...
3. Compatibility and security

The implementation of these methods should, ideally, not change
anything in the network, and all control changes are opt-in, so this
proposal is fully backwards compatible.

Controllers handling this data must be careful to not leak rendezvous
data to untrusted parties, as it could be used to intercept and
manipulate hidden services traffic.


After thinking through this, I wonder if the rendezvous data should
contain the decrypted cell, rather than the introduction point key and
the encrypted cell. That way, if an INTRODUCE event is exposed, only the
one rendezvous referred to by the event is vulnerable. (Exposure of the
introduction point key means that all introductions from that point are
vulnerable until it is rotated, however, there are other layers of
encryption protecting the INTRODUCE2 cells [but we shouldn’t rely on
these, because we want defence-in-depth].)

This is also slightly more efficient, as we are transmitting less data
in the INTRODUCE event.

The drawback of this change is that decryption places slightly more load
on the tor instance that receives the INTRODUCE2 cell.


I don't have a particular opinion on which to pick. The proposal leaves 
this decision up to the implementation for exactly that reason.


There are several things to consider that I can think of:
 * If the crypto is done on the rendezvous side, HSes could potentially 
scale better and be more resistant to DoSes;
 * With up to 60 introduction points (= processes) made possible by 
OnionBalance, the perf difference may not matter any time soon, and 224 
should make HSes perform better anyway;
 * If the crypto is done on the introduction side, DH replays could be 
detected better, which may be good against DoSes;
 * The controller is considered trusted, and connections between the 
controllers needed for this proposal can be encrypted;
 * The overhead of constantly adding the same key into the events can 
largely be negated by using a fast compression algorithm such as Snappy 
-- although I don't think that these introduce events will ever become a 
bottleneck.


Tom


PS: So far this thread has been between Tim and myself... Does anyone 
else have an opinion? ;-)

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

Re: [tor-dev] ResearchEthics

[Aaron Johnson]

> https://trac.torproject.org/projects/tor/wiki/doc/ResearchEthics
> 
> Any number of problems and obstacles to legitimate
> research areas exist with this…

I would be interested in any others that you have other than the one you bring 
up below.

> "
> It is not acceptable to run an HSDir, harvest onion addresses, and do
> a Web crawl of those onion services.
> Don't set up exit relays to sniff, or tamper with exit traffic.
> "
> 
> Assuming such bans, how is one supposed to legitimately
> research and report on the real makeup of onion or exit space?
> These are significant unanswered questions regarding tor use.

I happen to agree with requesting that nobody do harvesting of onion addresses 
on HSDirs. Tor will in fact soon make this impossible by changing the 
descriptors to hide the onion address. In the meantime, relays that are 
currently observed to do this are being kicked out of the network by the 
DirAuths. The reason is that people believe that Tor users should be able to 
run a hidden service without it becoming known to anybody else. This does limit 
information we can gather about the onion space, but such privacy is exactly 
what Tor is all about.

> Concentrate not on bans, which will be ignored by both legit
> and illegit researchers anyways, but on proper design for data
> handling and minimization, particularly being sensitive to the tor
> users and operators involved lest that data become compromised
> at any stage before final anonymization and wiping.

There are many types of activity that are “banned”, as you say, and I doubt you 
disagree with it all. For example, one should not gather data about all the 
client IPs observed and when they were using Tor. No, we can’t tell if anybody 
is doing this. That doesn’t mean that Tor can’t request that it never be done. 
And “legitimate” researchers will absolutely follow community standards. First, 
because most of them aren’t jerks. Second, because conference program 
committees and journal editorial boards can and do reject papers for unethical 
behavior.

Best,
Aaron
___
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

[Paul Syverson]

On Wed, Sep 30, 2015 at 05:12:53PM +0200, Tim Wilson-Brown - teor wrote:
> Hi All,
> 
> Do you know a use case which needs Single Onion Services and NAT punching?
> 
> We’re wondering if there are mobile or desktop applications /
> services that would use a single onion service for the performance
> benefits, but still need NAT punching. (And don’t need the anonymity
> of a hidden service.)
> 
> Single Onion Services:
> * can’t do NAT punching, (they need an ORPort on a publicly
>accessible IP address),
> * locations are easier to discover, and
> * have lower latency.

Note that we considered making the single-onion services proposal (Tor
Proposal 252) include a NAT punching option. We didn't for a
few reasons.

1. Get the proposal out there. We can always add other protocols
either as part of the proposal or in a new one.

2. Double-onion services already provide NAT punching. The performance
delta of a sesqui-onion service (onion circuit on one side, roughly
half an onion circuit on the other) is not as significant as for plain
single-onion services and so yet another protocol to design, maintain,
keep compatible, be a counter to new design innovations might not be
worth it.

3. Most importantly, Tor generally follows the onion routing
philosophy of making trade-offs that make more users more secure with
an eye to making the most vulnerable or sensitive the norm.

On the one hand this means things like building for interactive
circuits w/ relatively low latency. This is in theory less secure
than, e.g., mix based remailers against global external observing and
partial relay compromising adversaries.  But in practice this leads to
much larger networks (making it harder to be global) and leads to
millions vs. hundreds of users with greater diversity of use
motivation and behavior (making the fact of usage less interesting of
itself to adversaries). Cf. my "Why I'm Not An Entropist".

On the other hand, we made the circuits use three relays. Most users
would most of the time likely be fine with a one-relay circuit. By
this I mean that an adversary that actually intends to do something
that is harmful to them intentionally or collaterally is likely
countered by a one-relay circuit, which would have a significant
performance impact. But this would mean that the users who do need and
use three-relay circuits would be much more rare and interesting, easy
to separate out, etc. Also the relays themselves become more valuable
to compromise (or set up your own, or bridge by owning the ISP) to an
adversary, which increases threat to the network itself. For these and
other reasons the default for tor circuits has three relays.

Now let's apply this worldview to the sesqui-onion NAT punching case.
In a world with single-onion services and double-onion services, this
is splitting off the double-onion anonymity set rather than the
single-onion set, regardless of what Tor Proposal the protocol is in.
So, the users that do require the server location protection that
double-onion services provide becomes a much smaller fraction making
them more likely interesting/worth pursuing/easier to identify/less
plausibly able to claim they only wanted to have better circuit
authentication/etc. than if the sesqui-onion services were not an
equally easy option to set up.

Also, given at best ambiguously user-understood threat environments,
and the well-documented tendency to choose in practice
performance/ease against hyperbolic discounting of threats for using
encryption and other security measures, we can assume that many will
opt for the better performing choice of sesqui-onion services when
perhaps they should not have. All the more so in the less-easily
understood case of onion services vs. plain
client-to-public-destination Tor use. Similar also to the one
vs. three relay option, pwning relays by any of the means mentioned
two paragraphs above makes it more effective to identify onion
services in the sesqui-onion case. Thus putting additional threat
pressure on the network itself. (I recognize similar things could be
said of single vs. double onion services in general. I have some
responses there, but I am already going on overly long as usual.)

These to me are counter-arguments to the advantages of a NAT punching
sesqui-onion protocol. I don't question the many clear advantages of
having such a protocol. But to me the above make it too great a
trade-off to develop them for easy deployment. I don't think the
answers concerning this trade-off are just obvious. So I encourage
continued examples and discussions of their use. But I would like to
be convinced that they outweigh the above (and possibly other examples
of) trade-offs before I would support their development and promotion.

aloha,
Paul
___
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

[Aaron Johnson]

NAT-punching in single-onion services seems to me to be a clear functionality 
improvement with an unclear effect on security.

The NAT-punching protocol that we settled on at the dev meeting was:
  1. The single-onion service (SOS) maintains a direct connection to an IP.
  2. A client does an HSDir lookup
  3. A client simultaneously creates circuits to the IP and an RP of its 
choosing.
  4.  The client sends a connection request to the SOS via the IP, indicating 
the desired RP.
  5. The SOS creates a direct connection to the RP, completing the connection.
This makes the connection indistinguishable from an HS connection to the 
client’s guards and middles, except for the end-to-end latency of the RP 
circuit. The IP and RP can identify the SOS, which they can already do with a 
non-NAT SOS. So all we’ve done is make SOS clients look like HS clients 
instead. In fact, I like this so much that I would even argue to make all SOSes 
at least mimic this rendezvous behavior (which is easy to do even if they don’t 
want to maintain an IP connection).

With this understanding, it is clear that your arguments only work to argue 
that SOSes in general are not a good idea. Which is a fine enough argument. I 
think it’s a reasonable hope that new services are attracted to Tor as SOSes 
instead of being “converted” from HSes. Also,I see SOSes as the next step 
towards replacing insecure Internet protocols. They should be seen as a 
replacement for exit traffic in general and not a competitor to hidden 
services. And given that SOSes share 3-hop client circuits with exit circuits, 
perhaps we should try and make those two cases indistinguishable. It doesn’t 
seem impossible, although it probably requires adding some dummy steps to exit 
connections.

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