Re: [tor-dev] A series of questions about Tor (m1 support, forward secrecy, v3 auth)

[George Kadianakis]

Holmes Wilson  writes:

> Hi everyone,
>

Hello Holmes,

here are some attempts to answer your questions.

> 2. FORWARD SECRECY
>
> Is there a good source for documentation on how forward secrecy works in Tor, 
> and on what security guarantees it provides? Googling finds things like this 
> reddit post (https://www.reddit.com/r/TOR/comments/cryrjx/does_tor_use_pfs/) 
> but I can’t find any detailed information about it, what threat models it 
> fits, etc. 
>
> One specific question is, if two users are communicating by sending messages 
> over a connection to an onion service (like ricochet) and an attacker 
> surveils their internet traffic and compromises their devices at a later 
> date, will the attacker be able to recover the clear text of their 
> conversation? When are keys for a given connection destroyed? Does it happen 
> continuously throughout the course of a Tor connection? Or on the creation of 
> a new circuit? Or what?
>

tl;dr Onion service sessions are protected with forward secrecy.

In particular, v3 onion services use a variant of the ntor key exchange
(see [NTOR-WITH-EXTRA-DATA] in rend-spec-v3.txt) when doing their
rendezvous. The ntor key exchange provides forward secrecy which means
that if the long-term public key is compromised (e.g. by pwning their
device), the session remains secure as long as the short-term ephemeral
session secrets don't get compromised.

The forward secrecy "happens" at the creation of the rendezvous circuit
and not continuously through the course of a Tor connection (i.e. no
ratcheting happens). This means that if an attacker has the transcript
of the entire circuit, and manages to compromise the session in its
midpoint, it should be possible for her to decrypt back to the start of
the session.

Here is the original ntor paper:  http://www.cypherpunks.ca/~iang/pubs/ntor.pdf

> 3. V3 AUTH AND DOS ATTACKS
>
> Does v3 onion authentication protect against DOS attacks? That is, can 
> someone who is not authorized to connect to an onion address with 
> authentication enabled still cause problems for that onion address? Can they 
> connect to it at all, in the sense of being able to send data to the tor 
> client at that onion address? Or does the Tor network itself prevent this 
> connection from even happening? 
>
> A related question is, if we’re looking to deny connections to an onion 
> address to any unauthorized users, and we’re considering turning off onion 
> authentication and implementing some standard authentication scheme that 
> seems fairly well-supported at the web server layer, is there any 
> security-related reason why we would be better off using Tor’s own 
> authentication instead? Using our own authentication scheme will be a bit 
> easier to control, rather than having to send commands to Tor (and possibly 
> restart it for removing users?) but I’m wondering if there are security 
> properties we lose by doing that. 
>

Like hackerncoder said, v3 onion authentication protects against DoS
attacks because the access control happens very early in the connection
process.

An attacker with no access to the auth keys cannot decrypt the onion
descriptor, which means that they cannot do introduction or rendezvous
with the onion service. It so happens that all onion DoS attack vectors
are during intro or rendezvous, and hence v3 onion auth protects against
them.

WRT your second question, if you swap the client authentication with
your own application-layer authentication scheme, you are losing the
above properties, since it means that an attacker will be able to reach
the web server before they get denied access. This means that the
attacker will be able to abuse DoS vectors during the intro and
rendezvous steps of the connection.

There is something to be said about the UX issues of having this custom
authentication mechanism and it not being in the application-layer, and
this is something we should be improving in the future.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Scalability or Onionbalance for v3 ephemeral/ADD_ONION services

[George Kadianakis]

Holmes Wilson  writes:

> Hi George,
>
> Sorry for the slow reply here! Just getting back to this. 
>
>>> For our application (a messaging app) it would be super useful to get the
>>> full list of known online (or recently seen online) onion addresses in
>>> possession of some frontend key. This would let us use onionbalance for
>>> peer discovery instead of blindly trying the set of all known peers, which
>>> won't work well for large groups / large numbers of peers.
>>> 
>> 
>> Hmm, can you please give us some more details on what you are looking
>> for? What is peer discovery in the above context, and what do you mean
>> with "full list of ... onion addresses in possession of some frontend
>> key"? I'm asking because the frontend key of onionbalance is also the
>> onion address that users should access.
>
> Our context is we are building a Discord-like team messaging app where peers 
> are connected to each other over Tor, via onion addresses, rather than to a 
> central server. So each user connects to a few peers, and messages travel 
> across peers on a gossip network, and there’s a mechanism for syncing 
> messages you missed, say, if you went offline for a bit. 
>
> One problem we have is, when a new peer comes online, how do they know which 
> other peers are online? Right now, they can try all of the peers they know 
> about, or perhaps try recently-seen peers. But if there are hundreds of peers 
> and only a few are currently online, it will be necessary to try many 
> unreachable peers before finding one who’s online. So that’s not ideal.
>
> One solution to this would be for each online peer to host the same onion 
> service, using a shared key, in addition to their normal peer onion address. 
> And at this address they could return a list of peers they knew were online. 
> So a user would just have to connect to one address, at which point the Tor 
> network would connect them to some online peer, and then that peer could tell 
> them about other online peers. The problem with this approach, as pointed out 
> by folks on this list, was that all those peers would have to really trust 
> each other, since any one of them could go rogue and host malicious 
> information instead of the peer list, gumming up the works. I’m not sure this 
> is a fatal problem, since it would still *help* in cases where there wasn’t a 
> malicious peer, and users could still fall back to the slower method of 
> trying every peer. 
>
> But what I’m wondering is whether there is any mechanism for a bunch of onion 
> addresses that *don’t* completely trust each other to share a “meta” onion 
> address on the Tor network, such that when the user looks up that identifier 
> instead of getting connected directly to whatever content one of those onion 
> addresses is serving, they get a list of all onion addresses that hold the 
> keys to the “meta” address. 
>
> It’d be like asking Tor, "show me a list of all onion addresses that have 
> registered this meta address.” Sort of like asking, “show me a list of 
> mirrors for this address…” at which point the user could try connecting to 
> one or more of them, but would not have as serious problem if one of the 
> sites went rogue and started serving useless content.
>
> This is a bit of a long explanation, and my guess is that there isn’t 
> anything like this and that the above scenario isn’t common enough to be 
> worth targeting, but I was curious if anything like this had ever been 
> discussed.
>

Hello Holmes,

I don't know much about these kind of P2P protocols, but my intuition is
that this "get list of online peers" should be handled on the gossip
protocol layer, and not on the Tor layer. As a naive strawman example,
each peer can keep its own list of online peers and return it when asked.

I feel like the idea of "connect to meta address to get list of online
peers" is kinda the same as "ask any peer you can find for the list of
online peers". That's because with the meta address idea you don't have
a way to know whether the meta address result is a trusted peer; in the
same way that you don't know whether the peers you get through gossip
are trusted peers. This means that in either case you will have to
handle malicious nodes somehow.

In any case, the "meta" address idea is not handled natively by Tor
right now. You could in theory do it by having multiple peers share the
same private key, but I don't know if the results would be ideal. For
example, a single such peer can DoS the system by continously sending a
corrupt onion descriptor for the meta address.

Good luck with designing your P2P protocol!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev