Tor: 1100 relays still run end-of-life tor versions(lists.torproject.org)
lists.torproject.org
Tor: 1100 relays still run end-of-life tor versions
https://lists.torproject.org/pipermail/tor-relays/2018-May/015124.html
49 comments
Is there anyone that still believes TOR will protect him from state actors?
It's nice that people still run exit nodes, but it's so expensive and dangerous that you cannot expect a satisfactory number of nodes to be run for moral reasons and not for monetary/surveillance ones.
Also since most of the nodes are run on VM instances, a few companies could potentially recover all the routing and keys from the servers RAM if they feel like it. They're not going to do it for the average joe, but things like the Patriot act and it's European equivalents make sure intelligence agencies can do it if they want.
It's nice that people still run exit nodes, but it's so expensive and dangerous that you cannot expect a satisfactory number of nodes to be run for moral reasons and not for monetary/surveillance ones.
Also since most of the nodes are run on VM instances, a few companies could potentially recover all the routing and keys from the servers RAM if they feel like it. They're not going to do it for the average joe, but things like the Patriot act and it's European equivalents make sure intelligence agencies can do it if they want.
I'm just throwing an idea out here. It is often stated that running Tor exit nodes is both costly and dangerous. For understandable reasons. Yet the network needs more such nodes, to defeat the scenario of one powerful entity operating hundreds of exit nodes. It would be nice if even ordinary Tor users can run transient exit nodes. Now as it stands, nobody will do it. So why not change the functionality of Tor such that it becomes possible for a user to operate an exit node for a whitelisted list of sites (either based on IP or domain names) that they are willing to funnel traffic for? It's still better than giving up and letting a majority of exit nodes be controlled by state actors and other powerful entities right? Serving traffic only for a set of white-listed endpoints can considerably reduce the risk of running afoul of local law enforcement.
I realise this effectively cripples Tor, but normal "uncensored" exit nodes can still operate, by those willing to run them.
I realise this effectively cripples Tor, but normal "uncensored" exit nodes can still operate, by those willing to run them.
I've seen this idea thrown around in Tor mailing lists as well.
The developers basically replied that while they're not happy about how Tor is used by some people, if they started censoring some things, they would eventually be required to censor others. At that point, what is really the point of Tor - just chain some VPNs together.
The developers basically replied that while they're not happy about how Tor is used by some people, if they started censoring some things, they would eventually be required to censor others. At that point, what is really the point of Tor - just chain some VPNs together.
The point would be the stronger anonymity offered by Tor, whereas with VPNs, you're basically at the mercy of the service providers not to keep logs. Also the developers needn't censor anything but merely build in a mechanism that individual node operators can use or not as they see fit. Like adblock lists, the lists themselves would presumably be made and circulated by interested individuals, and nothing to do with Tor devs.
Anyway, thinking further, I realised even a whitelist can be bypassed in various ways to do illegal stuff, so you'd still need to be quite prepared and legally informed before running an Exit node. :-(
Anyway, thinking further, I realised even a whitelist can be bypassed in various ways to do illegal stuff, so you'd still need to be quite prepared and legally informed before running an Exit node. :-(
Yes I believe that TOR will protect against state actors in the very similar way that leaks and investigative journalism protect against corruption and abuse. It increase costs where its too costly for the average case and for the super important and critical cases then the cheaper and more available methods are likely to bring results way before such costly attacks are even considered.
For example, if they want to know who owns a specific tor hidden service they could get the lawyers and higher ups to pressure amazon and microsoft to dump rams of all their customers (and manage all the secrecy so to not create bad PR), or they could just make a search on their vulnerability database and attack the website directly. They can also just put a well trained and experienced detective to find traces from the operators that they might accidentally make on facebook, stackoverflow and so on. They can have an agent go under cover or try recruit people close to the target. Each of those have costs and risk that is far cheaper than attacking the tor network, and having read a lot of stories in regard to the silk road, wikileaks and other users of tor it seems that this is indeed the primary way state actors operates.
For example, if they want to know who owns a specific tor hidden service they could get the lawyers and higher ups to pressure amazon and microsoft to dump rams of all their customers (and manage all the secrecy so to not create bad PR), or they could just make a search on their vulnerability database and attack the website directly. They can also just put a well trained and experienced detective to find traces from the operators that they might accidentally make on facebook, stackoverflow and so on. They can have an agent go under cover or try recruit people close to the target. Each of those have costs and risk that is far cheaper than attacking the tor network, and having read a lot of stories in regard to the silk road, wikileaks and other users of tor it seems that this is indeed the primary way state actors operates.
You need all nodes in the path, not just exit nodes, to identify source. And traffic already HTTPSed, so controlling exit node won't help. So far I've never heard of state actors beating TOR. They usually exploit things like TOR browser vulnerabilities, etc.
TOR was developed to protect american spies, so it's exactly its purpose: to defend against state actors.
TOR was developed to protect american spies, so it's exactly its purpose: to defend against state actors.
no. if you control the entry and exit nodes, you can identify the source using traffic correlation analysis
Tor project should implement subscription model to pay for running thousands of tor nodes.
Users pay its yearly fee via Bitcoin. Once a year.
Tor client authenticates to entry node with wallet ID. Node checks in blockchain that fee's been paid and forwards traffic.
Plus - clean nodes operated by trusted Tor project team.
Minus - experts need review that wallet checking is not a deal breaker. I have not really thought this through, just throwing ideas :))
Users pay its yearly fee via Bitcoin. Once a year.
Tor client authenticates to entry node with wallet ID. Node checks in blockchain that fee's been paid and forwards traffic.
Plus - clean nodes operated by trusted Tor project team.
Minus - experts need review that wallet checking is not a deal breaker. I have not really thought this through, just throwing ideas :))
i think this is a good idea, but it would require a lot of thought to ensure that the wallet linking requirement does not deanonymize paid users. i assume youre aware that BTC is not actually anonymous without taking some nontrivial steps.
Thank you :D I'm far from coins, but heard that monero may be more anonymous.
But it does not kills the idea, imho. Buying and paying coins anonymously is a different, independent area.
Came to my mind that this subscription model may spawn several Tor networks, trust whichever you want, like with VPN providers. Just keep the Tor code maintained by the public.
And several networks may use each other's nodes ... Cyberpunk in its best
But it does not kills the idea, imho. Buying and paying coins anonymously is a different, independent area.
Came to my mind that this subscription model may spawn several Tor networks, trust whichever you want, like with VPN providers. Just keep the Tor code maintained by the public.
And several networks may use each other's nodes ... Cyberpunk in its best
> I'm far from coins, but heard that monero may be more anonymous
i'm in a similar position. i find crypto interesting but i don't understand it well enough to be confident about the anonymity provided. a concern i have is that people are already looking for ways to deanonymize crypto wallets and tor users separately. to link tor to crypto wallets would seem to increase the attack surface to deanonymize tor users. i'll leave it to those more knowledgeable than me to say how much of a risk this really is.
again, i do think it is very important for the long term viability of tor to create more incentive for users to support it financially.
i'm in a similar position. i find crypto interesting but i don't understand it well enough to be confident about the anonymity provided. a concern i have is that people are already looking for ways to deanonymize crypto wallets and tor users separately. to link tor to crypto wallets would seem to increase the attack surface to deanonymize tor users. i'll leave it to those more knowledgeable than me to say how much of a risk this really is.
again, i do think it is very important for the long term viability of tor to create more incentive for users to support it financially.
> very important for the long term viability of tor to create more incentive for users to support it financially
Yeah, that was the idea, nothing grows without money. Trust me, people will pay money for Tor once model is proven to be secure and anonymous.
There is private networking, Tor, but it needs private money to run.
There is private money, coins, but it needs private networking to run.
Lets merge them together, somehow :) Onion Coin need to be established in .onion domain only, dark web (onion) exchanges converting Onions to 'meat' (a.k.a IPV4) internet coins, to pay for Tor nodes.
Got me googling stuff (yeah, shut up), found deeponion.org - cryptocurrency sent through the TOR :)
Yeah, that was the idea, nothing grows without money. Trust me, people will pay money for Tor once model is proven to be secure and anonymous.
There is private networking, Tor, but it needs private money to run.
There is private money, coins, but it needs private networking to run.
Lets merge them together, somehow :) Onion Coin need to be established in .onion domain only, dark web (onion) exchanges converting Onions to 'meat' (a.k.a IPV4) internet coins, to pay for Tor nodes.
Got me googling stuff (yeah, shut up), found deeponion.org - cryptocurrency sent through the TOR :)
A cryptocurrency implementing a zero-knowledge proof, like ZCash, may be a better choice here.
blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer
... time machines and Part 2. I Love this guy :)
... time machines and Part 2. I Love this guy :)
Thanks for posting, turns out one of these was mine. I forgot that it existed. 1213 days of uptime, still running Debian Wheezy (don't worry, i'm bringing it up to date now)
Tor project should have an official Docker image, we could just use it with watchtower, it would autoupdate itself.
https://github.com/v2tec/watchtower
https://github.com/v2tec/watchtower
Does docker have container signing yet? If not, this sounds like it could be a disaster waiting to happen (just compromise dockerhuv credentials!)
There is, but it seems to be disabled by default.
https://docs.docker.com/engine/security/trust/content_trust/
https://docs.docker.com/engine/security/trust/content_trust/
This, actually, should be part of Docker itself. Thank you!
Thanks for running a Tor relay, even better, Tor relays! Please consider to check the right sidebar for new versions on https://blog.torproject.org/, add Debian repos from Tor Project instead of using default repo, and read [tor-relays]* mailing list routinely. It's a fun read comparable to Hacker News, well, sometimes.
* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-re...
* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-re...
I had the Tor Project's repos added, but I guess no auto updates.
Is it hard to create a Tor node? And is it juridically safe to be an owner of a Tor node?
I wrote this how to a few years ago: https://tor.stackexchange.com/questions/6567/how-do-i-manual...
Hopefully it's easier now than it was then.
As others said relay nodes are safe and low risk to run. I wouldn't run an exit node without looking into the legal risk and having a plan.
Hopefully it's easier now than it was then.
As others said relay nodes are safe and low risk to run. I wouldn't run an exit node without looking into the legal risk and having a plan.
It is pretty easy to setup if you know the basic of administrating a GNU/Linux or BSD machine. It is better if you also know a bit about security on those system too (at least how to configure the firewall).
When it come to the legal part, it depends.
Being a exit-node can be very tricky. In some country, you will have to register has a telecommunication provider in order not to be considered liable for whatever comes out of your relay.
Being a guard-node (the "entry" node for tor client) is usually safe but can still create some trouble. For example, the virus WannaCry was using Tor to connect to its C&C servers. Due to this, some Tor guard node got seized by the French police because they saw WannaCry connect to the IP of those guard node and I guessed, decided that it was necessary to seize them for their investigations ...
But you can configure your node to never be chosen has a guard node and to be just a relay and not a exit node. The node will be the middle man between a guard and a exit node and that should be completely safe, unless you live in a country where technology to circumvent censorship are prohibited.
When it come to the legal part, it depends.
Being a exit-node can be very tricky. In some country, you will have to register has a telecommunication provider in order not to be considered liable for whatever comes out of your relay.
Being a guard-node (the "entry" node for tor client) is usually safe but can still create some trouble. For example, the virus WannaCry was using Tor to connect to its C&C servers. Due to this, some Tor guard node got seized by the French police because they saw WannaCry connect to the IP of those guard node and I guessed, decided that it was necessary to seize them for their investigations ...
But you can configure your node to never be chosen has a guard node and to be just a relay and not a exit node. The node will be the middle man between a guard and a exit node and that should be completely safe, unless you live in a country where technology to circumvent censorship are prohibited.
A TOR relay is pretty safe. You're just a middle-man and have no clue about what's going on.
Your IP is still going into every single blacklist of corporate gateways though (because F5, etc. don't care): so don't host multiple services on that IP/server.
An exit node is the most dangerous position to be in, because that's were all the bad stuff can be seen.
Your IP is still going into every single blacklist of corporate gateways though (because F5, etc. don't care): so don't host multiple services on that IP/server.
An exit node is the most dangerous position to be in, because that's were all the bad stuff can be seen.
It's very easy, but yes, you cannot control what data exits it.
I'm just as curious as you what the GP's internet setup looks like.
I'm just as curious as you what the GP's internet setup looks like.
The GP didn't necessarily say he was running an exit relay, only that he was running a relay of some kind. As far as I know it's a lot less perilous to run a middle relay.
snap install tor-middle-relay
https://snapcraft.io/tor-middle-relay
https://snapcraft.io/tor-middle-relay
The same happened to me. I was pretty sure that the VPS that was running the node was shutdown but it turn out it was still running.
Where does one host this without getting SWATTED?
> We encourage everyone to configure their relays to do updates automatically
I understand the general security benefits of automatic updates, but on something with as big a target on its back as Tor, isn't it asking for trouble? An attacker could poison an update and make vulnerable the entire network for as long as it takes for the Tor Project to discover the problem and patch it.
How does the security professional balance such issues? I can imagine mitigating the risk with rolling updates, but the 0-days aren't patched immediately.
I understand the general security benefits of automatic updates, but on something with as big a target on its back as Tor, isn't it asking for trouble? An attacker could poison an update and make vulnerable the entire network for as long as it takes for the Tor Project to discover the problem and patch it.
How does the security professional balance such issues? I can imagine mitigating the risk with rolling updates, but the 0-days aren't patched immediately.
How about if the node just shutdown after X period of no updates? It would be inconvenient for the admin and users specifically using that node, but would be a win for overall network security.
It could still expose a vulnerability meaning someone could kill the whole network, but that’s better than compromising it.
It could still expose a vulnerability meaning someone could kill the whole network, but that’s better than compromising it.
This is a great idea. I would make it configurable, with a vaguely worded configuration directive like:
DisableAutoDisable I_Know_What_I_Am_Doing
Tor routes more packets through "trusted" nodes that have a history of being fast, and so on. I wonder whether an automated kill switch would affect those statistics (resulting in possibly lower overall network bandwidth because the trust level of most nodes would be worse).
If trust is quantified by node, then surely it could just be reduced as a function of outdatedness.
If they're not updating their main software, what makes us think they're patching the host? It makes me wonder what percent of those 1100 are compromised.
For example the 1213 days of presumably no updates by f2n (mentioned in another comment: https://news.ycombinator.com/item?id=17150526 )
For example the 1213 days of presumably no updates by f2n (mentioned in another comment: https://news.ycombinator.com/item?id=17150526 )
The attack surface matters. If the only exposed services are tor and sshd with public key authentication, one would need a vulnerability in either to compromise the host. How long ago was the last RCE on pre-authentication sshd?
(Of course, the lack of patches means that, once someone gets a RCE on either of these daemons, it's probably game over for the host.)
(Of course, the lack of patches means that, once someone gets a RCE on either of these daemons, it's probably game over for the host.)
Are they encouraged in their languages? How many of those relays are run by ESL operators? Maybe internationalization could improve the adoption speed or update speed or whatever you call that metric.
Do these operators actually even know they are EOL'd?
Do these operators actually even know they are EOL'd?
Not at all. They don't. Once the relays are up, many people simply forgot their existence at all, except they pay the bill. Just like many people's email server... And it's hard to contract many of them due to its decentralized nature, and most people don't actively follow [tor-relays] mailing list.
I'm the submitter. I see there is much misunderstanding and misinformation of Tor relays, even on Hacker News. I'm not a Tor dev, but I've been running a node for years, so I'd guess I somewhat have an authoritative opinion on this issue. The issue is simple and no conspiracy theory required.
1. This report mainly deals with Tor relays. A Tor relay is not a Tor Exit (well, you can argue Exit is a special type of relay). Tor relays can be run on all servers, optimally, with fixed IP address, bandwidth >10Mbps (do set appropriate bandwidth limit in /etc/torrc, or it burns all your bandwidth), anyone can help the network by running one. Tor relays only generate encrypted traffic to other Tor relays, and risk of running one relay is even lower than, let's say, a BitTorrent client. All you need is 5 lines of /etc/torrc, but better to tune the networking stack first.
2. Tor Project does not run any Tor nodes(x), most operators are enthusiasts, others are NGOs and privacy service providers doing a charity. If you read the [tor-relays] mailing list, you can see the people are just like those who run their personal email servers. Enthusiasts consist the people who are both networking hobbyist (understand networking, BGP, also familiar with network/server providers(x) around the world, for getting the maximum bandwidth, OVH, anyone?), and privacy enthusiasts (who know what is public key cryptography, uses GnuPG, follow security news, etc). There are lots of networking hobbyist (okay, not too many), and privacy enthusiasts. But only those people who have BOTH the hobbies, would eventually find their way to the [tor-relays] community, a small number.
2a. You see, the major obstacle of the growth is lack of publicity, and misunderstanding of Tor relays/exits. In 2014, EFF started a "Tor Challenge", and resulted a surge of 1,700 new nodes. Most of the nodes are STILL ONLINE (and probably being forgotten and hence outdated...). The speed of the Tor network has increased significantly due to the growth of interest since 2013, but more relays are always needed, currently there are less than 7000 nodes. Do you want to run? Start from https://trac.torproject.org/projects/tor/wiki/TorRelayGuide
3. Tor almost uses a rolling release model. The development pace is fast (but developers are not too many, need more), you can see Alpha versions being released almost every week. And they are more like a "mainline" version rather than a "alpha" version, and most of the time these "alpha" is already stable enough for casual uses. After the next alpha series is released, the current alpha is promoted to the "stable" series. This release model has some problems with traditional Linux/UNIX distros. For example, the Tor version in Debian (not Tor's) and OpenBSD's official repository is ALWAYS outdated by an entire series, since it has been freezed since distro's release date. Recently Tor just made another release, renders lots of current server being completely outdated.
4. Running a Tor Exit generally requires more cares of the servers, routinely respond to abuse mails, diagnose server problems and optimize performance. I haven't check, but I guess only a small percentage of these outdated versions are Exit.
4a. Running a relay is easy, most relay operators set up their servers in a fire-and-forgot basis, the servers are barely being touched anymore, once it has been configured and running correctly. Once the relays are up, many people simply forgot their existence at all, except they pay the bill. Just like many people's email server... And it's hard to contract many of them due to its decentralized nature, and most people don't actively follow [tor-relays] mailing list. Many careless operators also don't actively check their contract emails. Few of them even don't bother to leave contract information, or name their nodes (default: i_didnt_edit_config)...
5. Because Tor releases often, occasionally some people don't want to deploy updates until the next major maintenance reboot, because they don't want to lose the high uptime and large traffic they've waited to get for months (for new nodes, Tor traffic reaches to the maximum only after 3 weeks of continuous operation)...
TLDR, I guess automatic update is the solution, since the update is already signed. Also, we may need to make running Tor relay a more interactive process.
(x) Even authoritative servers are contributed to well-known members of the developer community, in a individual basis. (x) But don't use OVH for your new Tor relays, it's already the largest network of Tor nodes thanks to the cheap bandwidth.
1. This report mainly deals with Tor relays. A Tor relay is not a Tor Exit (well, you can argue Exit is a special type of relay). Tor relays can be run on all servers, optimally, with fixed IP address, bandwidth >10Mbps (do set appropriate bandwidth limit in /etc/torrc, or it burns all your bandwidth), anyone can help the network by running one. Tor relays only generate encrypted traffic to other Tor relays, and risk of running one relay is even lower than, let's say, a BitTorrent client. All you need is 5 lines of /etc/torrc, but better to tune the networking stack first.
2. Tor Project does not run any Tor nodes(x), most operators are enthusiasts, others are NGOs and privacy service providers doing a charity. If you read the [tor-relays] mailing list, you can see the people are just like those who run their personal email servers. Enthusiasts consist the people who are both networking hobbyist (understand networking, BGP, also familiar with network/server providers(x) around the world, for getting the maximum bandwidth, OVH, anyone?), and privacy enthusiasts (who know what is public key cryptography, uses GnuPG, follow security news, etc). There are lots of networking hobbyist (okay, not too many), and privacy enthusiasts. But only those people who have BOTH the hobbies, would eventually find their way to the [tor-relays] community, a small number.
2a. You see, the major obstacle of the growth is lack of publicity, and misunderstanding of Tor relays/exits. In 2014, EFF started a "Tor Challenge", and resulted a surge of 1,700 new nodes. Most of the nodes are STILL ONLINE (and probably being forgotten and hence outdated...). The speed of the Tor network has increased significantly due to the growth of interest since 2013, but more relays are always needed, currently there are less than 7000 nodes. Do you want to run? Start from https://trac.torproject.org/projects/tor/wiki/TorRelayGuide
3. Tor almost uses a rolling release model. The development pace is fast (but developers are not too many, need more), you can see Alpha versions being released almost every week. And they are more like a "mainline" version rather than a "alpha" version, and most of the time these "alpha" is already stable enough for casual uses. After the next alpha series is released, the current alpha is promoted to the "stable" series. This release model has some problems with traditional Linux/UNIX distros. For example, the Tor version in Debian (not Tor's) and OpenBSD's official repository is ALWAYS outdated by an entire series, since it has been freezed since distro's release date. Recently Tor just made another release, renders lots of current server being completely outdated.
4. Running a Tor Exit generally requires more cares of the servers, routinely respond to abuse mails, diagnose server problems and optimize performance. I haven't check, but I guess only a small percentage of these outdated versions are Exit.
4a. Running a relay is easy, most relay operators set up their servers in a fire-and-forgot basis, the servers are barely being touched anymore, once it has been configured and running correctly. Once the relays are up, many people simply forgot their existence at all, except they pay the bill. Just like many people's email server... And it's hard to contract many of them due to its decentralized nature, and most people don't actively follow [tor-relays] mailing list. Many careless operators also don't actively check their contract emails. Few of them even don't bother to leave contract information, or name their nodes (default: i_didnt_edit_config)...
5. Because Tor releases often, occasionally some people don't want to deploy updates until the next major maintenance reboot, because they don't want to lose the high uptime and large traffic they've waited to get for months (for new nodes, Tor traffic reaches to the maximum only after 3 weeks of continuous operation)...
TLDR, I guess automatic update is the solution, since the update is already signed. Also, we may need to make running Tor relay a more interactive process.
(x) Even authoritative servers are contributed to well-known members of the developer community, in a individual basis. (x) But don't use OVH for your new Tor relays, it's already the largest network of Tor nodes thanks to the cheap bandwidth.
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.
Okay, but that's not what TOR is trying to accomplish.
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.
That's just the way it works.
You can't make TOR work any
other way.
Okay, but that's not what TOR is trying to accomplish.
Well... 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?
So, 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.
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.
You 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.
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.
One 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.
Just because you have trouble imagining the implementation of such a thing doesn't mean I do, and doesn't make it impossible.
I 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.
1 - https://blog.torproject.org/tor-security-advisory-relay-earl...
2 - https://arstechnica.com/information-technology/2014/07/activ...