4 ms·
Given the project's goals, TOR cannot operate release versioning, interoperability, and backward compatibility like a "normal" open source project. Old version
by operandroid 8y ago
Given the project's goals, TOR cannot operate release versioning, interoperability, and backward compatibility like a "normal" open source project.
Old versions need to be something akin to a burnable one-time-pad, that gets burnt when deemed more vulnerable than it's up-versioned, more secure replacement.
In many ways, this kind of sucks as an idea, but in pragmatic terms, I just really wouldn't want idiots relaying traffic I'd feel paranoid about, in ways that'd cause me to lose sleep at night.
That said, I don't even think the routing protocol has honest merit. The idea that you should place an all-consuming degree of trust in the honor system surrounding exit node operators having total access to plain-text traffic is beyond-the-pale in its stupidity.
No one can field a satisfactory answer for me, regarding why it's okay that exit node operators have access to plain-text traffic.
Oh, because traffic analysis
is hard, and most exit node
operators are amateur hobbyists.
or maybe
That's just the way it works.
You can't make TOR work any
other way.
That's basically what I hear. It's the HAM radio excuse put another way. HAM radio has utility, bause we think it's neat. You don't need to worry, because it's free for everyone to use.
Okay, but that's not what TOR is trying to accomplish.
- gcb0 8y agoI agree that exit nodes are inherently bad and avoid it. but it is a good solution that is indeed akin to the utility HAM operators provide. I fail to see why it's not.
- yjftsjthsd-h 8y agoWell... That is how it works. Either traffic stays on tor (hidden service) or it leaves and the exit node can see it. This is a good reason to use HTTPS. How would you like it to work?
- operandroid 8y agoSo, TOR works in this way, but some other hypothetical ideal system would never work this way. An ideal system would operate in such a way that reading an ordinary public resource requires no single peer. If I want to simply read a wikipedia page, no single individual should be capable of knowing that I requested that page, and be tasked with the entire responsibility of proxying my request. No single peer should even know that a wikipedia page is what I asked for, who I asked for content from, or where I've been and what I've been doing. Right now HTTPS offers content privacy, but no meta data privacy. TOR offers a degree of meta data privacy, but no guarantee of content privacy. Even with the two combined, the TOR exit node can still understand that someone logged into Gmail, and someone probably tried to send a message with an overall length of ~2MB. With a strategic vantage point, enough facts could become evident, that TOR would fail to offer enough protection, and still out someone trying to accomplish a secret task with TOR. It should be possible to provide both content privacy and meta data privacy, so that my solid gold widget factory plans are mailed safely to my vacation home, and no one knows that I mailed them to myself, that I mailed anything at all, or what I mailed if that's what I was doing. I don't care about how "it" works, if TOR can only suck one way, and can't not suck some other way. I want something that doesn't suck. I already said I don't want TOR. TOR doesn't need to be something else. It just needs to stop telling people it's something better than it actually is.
- eklitzke 8y agoYou can't magically make bridging to insecure services work in a secure way. If you want to use Tor to bridge to unencrypted HTTP, at some point someone needs to actually make an unencrypted HTTP request. And likewise for HTTPS requests. HTTP is a stateless protocol, which is why what you're describing is not possible. You could design a protocol that let you split up requests in the manner you describe, but that protocol would not be HTTP.
- operandroid 8y agoOne can obfuscate an extremely live distributed, obfuscated cache that mirrors public resources, and that's not magic. Just because you have trouble imagining the implementation of such a thing doesn't mean I do, and doesn't make it impossible.