[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] A series of questions about Tor (m1 support, forward secrecy, v3 auth)
Disclaimer: I do not know that much about Tor, but I can read (and have
read parts of) the specifications
And sorry to Holmes for sending this twice. I'm not used to mailing
lists, "reply" is right next to (and before, so when running on
auto-pilot that's the first thing I see) "reply list".
> Hi everyone,
>
> A few disjointed questions that have come up recently in our work
with Tor:
>
> 1. PERFORMANCE ON M1 / ARM64
>
> We just got a report from a user that the tor binary for Mac was
using much more CPU on Apple Silicon / M1 than it used on Intel. Has
anyone scene anything like this? Is there an arm64 build of tor binary
for Mac, existing or in the works?
>
> (Related: do Tor developers have a few M1 Macs to test on? We could
probably donate one if not!)
>
> 2. FORWARD SECRECY
>
> Is there a good source for documentation
In general I would point at https://spec.torproject.org, they are
technical and long when you just want info on one specific thing, but is
still good nonetheless. In particular you may find rend-spec-v3
(onion/hidden services, v3) and tor-spec good.
> 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.
In tor-spec there point "2" for connections[1], they are made with TLS,
so if supported by both client and relay it may be it is possible that
FS happens here.
> 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?
>
> 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?
No. The rendevouz specifications (v3) [2] make it so only authorized
clients (if enabled) are able to figure out (e.g.) the introduction
points of the onion service, thereby being unable to contact it.
"The second layer of descriptor encryption is designed to protect
descriptor confidentiality against unauthorized clients. If client
authorization is enabled, it's encrypted using the descriptor_cookie,
and contains needed information for connecting to the hidden service,
like the list of its introduction points."
> 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 >
> Thanks!
>
> Also, apologies if any of these questions aren’t clear or well-formed!
>
> Holmes
>
[1] https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n196
[2] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1287
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev