5 ms·

That’s probably one of the reasons that TLS over Tor has remained such a tough nut, with people who otherwise seem to have tinfoil hats claiming that it’s not n

That’s probably one of the reasons that TLS over Tor has remained such a tough nut, with people who otherwise seem to have tinfoil hats claiming that it’s not needed because Tor provides enough protection. My opinion is that you want that end to end protection for the same reason you want it on the clearnet - to make so nobody along the way is sniffing your traffic. (that includes both exit nodes and any middle nodes that might be taking advantage of an unknown flaw or bias) Having a bunch of Tor site certs in your MacOS keychain has its own issues, so what is really needed is a way for Tor browsers to accept those certs directly without using the OS trust stores. The current practice of authenticating the remote site by PGP signature would remain more or less the same - you just wouldn’t have exit nodes sniffing traffic. I’m also convinced that the whole reason Google has pushed TLS so hard isn’t some noble quest to protect people’s privacy and freedom of speech - it’s more to keep people from blocking their advertisements, which isn’t nearly so sexy an argument, but it has brought good benefits for a lot of people.

schoen 4y ago
> people who otherwise seem to have tinfoil hats claiming that it’s not needed because Tor provides enough protection I've been on the side of advocating for it, but the other side isn't making an obviously ridiculous argument. The onion protocol itself negotiates an end-to-end cryptographic session, authenticated by the onion site's public key, between the onion site and the end user. There's not cleartext traffic sent between a Tor exit node and the onion site or anything! My argument in favor of TLS to onion sites was that, at least as of onion protocol v2, the cryptographic session was not itself TLS, and its security and threat model hadn't been as extensively reviewed as those of TLS. So it might turn out that there was something suboptimal there that the rendezvous server could then use to perform a sophisticated cryptographic attack. I don't know if this is still true of onion protocol v3 or if the client-to-onion-site session is now also based on TLS.
- HackerNCoder 4y ago
  No, v3 isn't TLS either. TLS is only used as a connector between hops (so the client connect to a node using TLS, and the nodes connect to each other using TLS), but that is it. (I think, if I'm wrong do tell me. I didn't go check the spec)
  - schoen 4y ago
    OK, I checked and it's indeed still not TLS. https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/rend-spec-v3.txt#L2150 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/r... I think the main question would be: are there cryptographic attacks that a rendezvous server could do that wouldn't work against TLS?
bauruine 4y ago
You seem to mix up a lot of stuff here. The Tor Project thinks TLS for onion services is unneeded because they ARE end to end encrypted by design. The address itself is an ed25519 public key. And exit nodes are not involved in connecting to an onion service at all. For connections to the clearnet it was always highly recommended to only use TLS and recent Tor browsers have now finally enabled https only mode that displays a big warning if you try to connect to a http server.

schoen 4y ago

> people who otherwise seem to have tinfoil hats claiming that it’s not needed because Tor provides enough protection I've been on the side of advocating for it, but the other side isn't making an obviously ridiculous argument. The onion protocol itself negotiates an end-to-end cryptographic session, authenticated by the onion site's public key, between the onion site and the end user. There's not cleartext traffic sent between a Tor exit node and the onion site or anything! My argument in favor of TLS to onion sites was that, at least as of onion protocol v2, the cryptographic session was not itself TLS, and its security and threat model hadn't been as extensively reviewed as those of TLS. So it might turn out that there was something suboptimal there that the rendezvous server could then use to perform a sophisticated cryptographic attack. I don't know if this is still true of onion protocol v3 or if the client-to-onion-site session is now also based on TLS.

HackerNCoder 4y ago
No, v3 isn't TLS either. TLS is only used as a connector between hops (so the client connect to a node using TLS, and the nodes connect to each other using TLS), but that is it. (I think, if I'm wrong do tell me. I didn't go check the spec)
- schoen 4y ago
  OK, I checked and it's indeed still not TLS. https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/rend-spec-v3.txt#L2150 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/r... I think the main question would be: are there cryptographic attacks that a rendezvous server could do that wouldn't work against TLS?

bauruine 4y ago

You seem to mix up a lot of stuff here. The Tor Project thinks TLS for onion services is unneeded because they ARE end to end encrypted by design. The address itself is an ed25519 public key. And exit nodes are not involved in connecting to an onion service at all. For connections to the clearnet it was always highly recommended to only use TLS and recent Tor browsers have now finally enabled https only mode that displays a big warning if you try to connect to a http server.