A series of questions about Tor (m1 support, forward secrecy, v3 auth)
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 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? 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. Thanks! Also, apologies if any of these questions aren’t clear or well-formed! Holmes
Hi Holmes, On Fri, Jul 23, 2021 at 05:46:47PM -0400, Holmes Wilson wrote:
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?
Can you provide more detail about where this tor binary came from? Was it compiled from source or did it come from Tor Browser?
(Related: do Tor developers have a few M1 Macs to test on? We could probably donate one if not!)
We do not, but we'd be happy to discuss this with you! (I'll leave your other two questions to another tor person)
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?
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.
Thanks!
Also, apologies if any of these questions aren’t clear or well-formed!
Holmes
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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?
Can you provide more detail about where this tor binary came from? Was it compiled from source or did it come from Tor Browser?
It came from Tor Browser. So it was definitely an intel build. Is compiling for M1/arm64 as simple as compiling Tor on M1?
(Related: do Tor developers have a few M1 Macs to test on? We could probably donate one if not!)
We do not, but we'd be happy to discuss this with you!
Sure thing! I’ll email you directly. Holmes
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
Holmes Wilson <h@zbay.llc> 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.
participants (4)
-
George Kadianakis -
hackerncoder -
Holmes Wilson -
Matthew Finkel