4 ms·

Unless this has changed in the last few years, anyone can set up an exit node on Tor and begin proxying your traffic. It's just a switch in the config. The ris

Unless this has changed in the last few years, anyone can set up an exit node on Tor and begin proxying your traffic. It's just a switch in the config. The risk profile is somewhat lower now that HTTPS is prevalent, but it's still unnecessarily exposing at least one side of the conversation to literally anyone. Most of the time, you're better off just using your ordinary connection -- then you at least know that it's $LOCAL_TELCO sniffing the packets. Tor is excellent and it has uses, but I've had to explain to many people over the years that day-to-day browsing like checking email, checking bank accounts, etc., is far less safe through Tor than through a direct connection (at least for people in the US -- if you're using Tor for its intended purpose of thwarting oppressive regimes, crossing your fingers on the exit node lottery is probably preferable).

LMYahooTFY 7y ago
I don't really understand your point. I think most people would agree that TLS ought to be considered baseline, as sites are often (even in this thread) ridiculed harshly on HN for NOT using TLS. >The risk profile is somewhat lower now that HTTPS is prevalent, but it's still unnecessarily exposing at least one side of the conversation to literally anyone. Most of the time, you're better off just using your ordinary connection I think this is simply wrong, and lacks any threat model at all. Why do you care that encrypted bits can be sniffed by an exit node? The node can't even determine the 2nd hop, much less the origin.
- cookiecaper 7y ago
  > The node can't even determine the 2nd hop, much less the origin. The point is that users should be cautious about what they do over Tor because exit nodes can eavesdrop on (and potentially manipulate) the conversation. The onion mechanism isn't relevant here. It prevents peers from identifying each other within the onion, but it doesn't do anything to prevent the exit node from accessing the raw packets involved in the conversation -- indeed, the exit node must access those packets to proxy them. It's true that some of the traffic will be protected via HTTPS, but even encrypted packets can be made useful in various ways. The reality is that you're introducing a random computer into your network path and that you're trusting that computer to proxy your connection without a) eavesdropping; or b) modifying contents. The prevalence of HTTPS may or may not be sufficient mitigation for some, but any analysis of the propriety of Tor to access non-onion sites is fundamentally incomplete if it doesn't acknowledge, contemplate, and address the implications of inviting a random computer to MITM the connection (as the Tor FAQ has done for at least the last 10 years: https://2019.www.torproject.org/docs/faq.html.en#CanExitNodesEavesdrop https://2019.www.torproject.org/docs/faq.html.en#CanExitNode...).
  - LMYahooTFY 7y ago
    >The point is that users should be cautious about what they do over Tor because exit nodes can eavesdrop on (and potentially manipulate) the conversation. No, they can't. Unless you don't use TLS...which is addressed in the FAQ you linked. Who is it that can break TLS that you're concerned about? Again, without threat modeling this is all lacking a lot of context and purpose.
    - cookiecaper 7y ago
      HTTPS doesn't change the attack surface, it's just assumed to make it inaccessible. The exit node is still in the middle, and they absolutely can still listen. TLS will probably defeat script kiddies that are just after the "thrill" of voyeurism, but more advanced operators will make use of the attack surface you're offering them, even if they aren't ever able to decrypt the payloads (not necessarily a guarantee). There's lots of room to analyze and manipulate encrypted HTTPS traffic in interesting ways (SNI, non-secure cookies probably good starting points). TLS depends on correct configuration on both the client and server-side to be effective (and an interested proxy could try to modify the handshake to downgrade the connection's security). Whole versions of SSL/TLS have been deprecated after fundamental flaws were discovered; things like Heartbleed, POODLE, and Debian's low-entropy key debacle were all real things that made TLS much less secure than expected. An exit node operator that knew about these flaws prior to disclosure could've been having a heyday while users just said "Welp if I use HTTPS Everywhere it'll be fine". Even without bugs, when TLS is ostensibly working completely properly, the trust model is frequently hijacked. See the CACert wiki [0] for a list of several dozen well-known attacks on CAs, many of which allowed imposters -- on multiple occasions state-level actors -- to issue fake certificates for specific domains, which a malicious exit node could inject. The incontrovertible point is that using exit nodes exposes some prime attack surface to literally anyone, and yes, that's still attack surface, even if you're 1000% sure that your encryption is so super-duper strong that literally no one will ever be able to break it. The exposure is real, the risk is real even if not necessarily always immediate, and it needs to be considered along with the other factors. Any risk analysis that involves accessing clearnet resources via Tor exit nodes should contemplate this. [0] http://wiki.cacert.org/Risk/History http://wiki.cacert.org/Risk/History

LMYahooTFY 7y ago

I don't really understand your point. I think most people would agree that TLS ought to be considered baseline, as sites are often (even in this thread) ridiculed harshly on HN for NOT using TLS. >The risk profile is somewhat lower now that HTTPS is prevalent, but it's still unnecessarily exposing at least one side of the conversation to literally anyone. Most of the time, you're better off just using your ordinary connection I think this is simply wrong, and lacks any threat model at all. Why do you care that encrypted bits can be sniffed by an exit node? The node can't even determine the 2nd hop, much less the origin.

cookiecaper 7y ago
> The node can't even determine the 2nd hop, much less the origin. The point is that users should be cautious about what they do over Tor because exit nodes can eavesdrop on (and potentially manipulate) the conversation. The onion mechanism isn't relevant here. It prevents peers from identifying each other within the onion, but it doesn't do anything to prevent the exit node from accessing the raw packets involved in the conversation -- indeed, the exit node must access those packets to proxy them. It's true that some of the traffic will be protected via HTTPS, but even encrypted packets can be made useful in various ways. The reality is that you're introducing a random computer into your network path and that you're trusting that computer to proxy your connection without a) eavesdropping; or b) modifying contents. The prevalence of HTTPS may or may not be sufficient mitigation for some, but any analysis of the propriety of Tor to access non-onion sites is fundamentally incomplete if it doesn't acknowledge, contemplate, and address the implications of inviting a random computer to MITM the connection (as the Tor FAQ has done for at least the last 10 years: https://2019.www.torproject.org/docs/faq.html.en#CanExitNodesEavesdrop https://2019.www.torproject.org/docs/faq.html.en#CanExitNode...).
- LMYahooTFY 7y ago
  >The point is that users should be cautious about what they do over Tor because exit nodes can eavesdrop on (and potentially manipulate) the conversation. No, they can't. Unless you don't use TLS...which is addressed in the FAQ you linked. Who is it that can break TLS that you're concerned about? Again, without threat modeling this is all lacking a lot of context and purpose.
  - cookiecaper 7y ago
    HTTPS doesn't change the attack surface, it's just assumed to make it inaccessible. The exit node is still in the middle, and they absolutely can still listen. TLS will probably defeat script kiddies that are just after the "thrill" of voyeurism, but more advanced operators will make use of the attack surface you're offering them, even if they aren't ever able to decrypt the payloads (not necessarily a guarantee). There's lots of room to analyze and manipulate encrypted HTTPS traffic in interesting ways (SNI, non-secure cookies probably good starting points). TLS depends on correct configuration on both the client and server-side to be effective (and an interested proxy could try to modify the handshake to downgrade the connection's security). Whole versions of SSL/TLS have been deprecated after fundamental flaws were discovered; things like Heartbleed, POODLE, and Debian's low-entropy key debacle were all real things that made TLS much less secure than expected. An exit node operator that knew about these flaws prior to disclosure could've been having a heyday while users just said "Welp if I use HTTPS Everywhere it'll be fine". Even without bugs, when TLS is ostensibly working completely properly, the trust model is frequently hijacked. See the CACert wiki [0] for a list of several dozen well-known attacks on CAs, many of which allowed imposters -- on multiple occasions state-level actors -- to issue fake certificates for specific domains, which a malicious exit node could inject. The incontrovertible point is that using exit nodes exposes some prime attack surface to literally anyone, and yes, that's still attack surface, even if you're 1000% sure that your encryption is so super-duper strong that literally no one will ever be able to break it. The exposure is real, the risk is real even if not necessarily always immediate, and it needs to be considered along with the other factors. Any risk analysis that involves accessing clearnet resources via Tor exit nodes should contemplate this. [0] http://wiki.cacert.org/Risk/History http://wiki.cacert.org/Risk/History