Closed mx5kevin closed 4 months ago
Insufficient explanation, please be more explicit. What do you mean by "I2P/Tor anonymous mode"? How are you configuring the download?
Insufficient explanation, please be more explicit. What do you mean by "I2P/Tor anonymous mode"? How are you configuring the download?
Select the current torrent file/Privacy/Anonymous Only Mode selected with I2P Network and The Onion Router (Tor) Network Mode. I think the issue are in the Friends plugin. Try to send a message in the current torrent (Public chat option).
The Public IP network option are Disable in the torrent! Transferring the current torrent goes through the I2P network, but without the I2P network the users who are have the torrent file connecting and see each other who have that file directly!
Regarding the problem, I would like to emphasize that I do not know whether the Friends plugin are the problem or not, but from the message sender can see the user IP who are have activated this plugin, but does not sent any message, and vice versa. The problem occurs with the given torrent. Those users should not connect directly. I deleted all other torrents in the setup. The torrent itself is not transferred directly. The clients that contain the given torrent communicate with each other directly. The problem also occurs if the chat option is removed from the list only after the given torrent but enable before. I think the problem is that the plugin turns on the public network for the given torrent in the chat option, which it shouldn't.
In Tools/Options/Plugins/Friends i disable Friends Enabled option and Decentralized Chat Enabled option this setup looks like solving the problem. That plugin looks like bypassing the Anonymous Only mode setting, and leaking the users real IP even if the Downloader or other peers and Seeder both are using Anonymous Only mode without enabling the public network!
This is doubly dangerous because I2P nodes are public, and a malicious downloader can list BiglyBT and Vuze anonymous users because they are connected directly to it too without I2P protection. The security hole is difficult to notice because the download goes through the I2P network. But if someone looks at the communication on the firewall and knows the real IP of the seeder, seeders he sees his real IP address displayed without I2P you just have to watch the connected users in BiglyBT.exe direct connections.
Did you add the download and then change the enabled networks to remove the Pubic one and add I2P/Tor?
https://github.com/BiglySoftware/BiglyBT/wiki/I2P
NOTE: mixed torrents and I2P only torrents are handled separately within BiglyBT to prevent the correlation of mixed activity and pure I2P activity. If you add a torrent and subsequently amend its network availability (e.g. change it from pure I2P to mixed) then this will potentially reduce your privacy.
Did you add the download and then change the enabled networks to remove the Pubic one and add I2P/Tor?
The public network it was never active only Tor and I2P. When the torrent added at the first window Privacy button than the torrent started in Invalid State, than selected Anonymous Only Mode with I2P and Tor. Mixed Public/Anonymous Mix are not used in the setup! Than used the Force Start Option in the current torrent. The problem here is that a plugin bypasses the anonymous mode setting in the current torrent. The torrent goes through the I2P network, but the Friends plugin with the Chat option are not. If the chat allowed in a anonymous torrent this will break the anonymity in the current torrent.
The problem can be easily detected with the Comodo firewall. All you have to do is write down the IP address of the seeder machine. Than whit in another ISP network download the torrent using the I2P network. In my test are used 2 SEEDER PC, not downloader, these are have 100% of the files. There was communication between the two machines, but no download. Both mashine are used only the anonymous setup. In the BiglyBt.exe file. Back and forth, the real IP addresses of both computers could be detected. The real IP address can be detected not continuously, but by looking for the connection status in the firewall. The problem is not due to a configuration error. There could be no other file through which the two systems could communicate.
I clearly detected the problem the problem are with the Friends plugin. The only way to fix this Tools/Options/Plugins/Friends Dissalow Friends Enable and Decentralized Chat Enable options. If the chat option are deleted only in the current torrent, but somehow before allowed this will not help leaking the users IP. If the user deleting the chat window in the current torrent this is not help. I tested it several times and the problem only appears if the option is enabled. If the user has accidentally enabled it once, the problem appears for the given torrent. I can rule out all other possibilities because I have tested it several times and the problem can clearly be traced back to this. This plugin ignores the torrent Privacy settings.
Check View->Log Views->Message Sync for logs related to the decentralized chat
Check View->Log Views->Message Sync for logs related to the decentralized chat
I switched off the Friends plugin the log are empty. When was on, it connected to the public non anonymous DHT chat in the current torrent. For this reason, I checked the firewall on the other machine. I didn't turn it on separately on the other machine, but it was turned on by default and that are leaked the IP too. When I turned off the plugin on both machines, the problem went away. When i deleted only the chat tab on the current torrent that not helped.
This is the current torrent with the used setup:
I seed it only anonymous way, some users are seeding public anonymous way.
you sound like you know what you're doing, can you use wireshark (or similar) to capture some of these packets?
you sound like you know what you're doing, can you use wireshark (or similar) to capture some of these packets?
I won't over complicate it that much. I know Wireshark, but I did not analyze the packages in detail. It was detectable even without it the program are leaking and exactly what. Under Windows a firewall application what show in real time the TCP/UDP IN/Out traffic with port IP current program. I wrote down the machine's IP address and then watched to see if it could be detected from another Internet provider's network. While it was active the Friends plugin both mashines can detected each other real IP behind the I2P network. The two machines had no reason to communicate with each other outside of the given torrent. As soon as I completely turned off Friends and the chat plugin, direct communication (IP leaking) between the two machines stopped. However, the good news is that the torrent itself was not seeded/downloaded directly. Two separate internet networks are required for a professional examination of the problem with different IP address. The person who fixes this security hole must see that he managed to fix it well in real time. I can check in the later release whether the problem has been fixed or not. It's not that hard to reproduce. I'm a wifi hacker and amateur pyrotechnician. However, I am not a programmer, and I do not use Wiresark at such a professional level with frequent regularity that I analyze a program internet traffic about packet level for others. But I can review things in it in an amateur way in Wireshark. Whoever fixing the issues must analyze it in detail real time.
Yeah, but I don't have the setup to attempt to reproduce it which is why I asked for your help...
It isn't true that "The two machines had no reason to communicate with each other outside of the given torrent" - the DHT generates traffic between random nodes all the time. If your two machines share a particular country code, for example, then the (public) country specific chat may well generate UDP traffic between the machines, for example. In my case the "Message Sync" log shows
BiglyBT: Language: en_GB: Node status: live=36, failed=38, total=141, to_remove=13; messages=128
which is as a result of that decentralised chat finding other participating nodes.
Yeah, but I don't have the setup to attempt to reproduce it which is why I asked for your help...
It isn't true that "The two machines had no reason to communicate with each other outside of the given torrent" - the DHT generates traffic between random nodes all the time. If your two machines share a particular country code, for example, then the (public) country specific chat may well generate UDP traffic between the machines, for example. In my case the "Message Sync" log shows
BiglyBT: Language: en_GB: Node status: live=36, failed=38, total=141, to_remove=13; messages=128
which is as a result of that decentralised chat finding other participating nodes.
It's a simple thing that anyone can reproduce. If I were a developer, I would do it as follows. First making an anonymous torrent. And I observe that there is direct communication between the two machines from two separate networks or not. If the two systems regularly communicate directly with each other, there is a serious problem. Then I'll play around with the features. In chat, and torrents can imagine that there are similar problems. I'm thinking here that even chats and torrents can be read as simple text files from the user's internet service provider. With artificial intelligence, the authorities can filter such security holes even more effectively from the uses ISP side. In the case of torrents, there are test downloads with whom the machine communicates, how much data has been downloaded from whom, what IP addresses the machine communicated with with time stamps. The authorities are the first to crack down on pyrotechnic content to monitor users. Merging public and anonymous networks has a future in torrent. But it needs to be secure and easy to use in order to be widely used. For this project, a few settings should be made default, which I already wrote about a long time ago, and this leak should be eliminated. Very complicated things should not be need implemented here to fix all these problems. The goal of those who share files is that the users who download them effectively help the seeding of the files and that the network is secure. This torrent client knows something that the others don't. Can bridging public torrents to the I2P anonymous network (if in the future the default settings easy way support this in the future). And most people will not use paid VPNs. Users have indicated in several places that there is a wide demand for a function that has been implemented here. And several programmers are already planning to integrate I2P in different torrent clients. But currently, of all similar projects that I know of, this one works properly.
"two separate networks". where do I get them from?
"two separate networks". where do I get them from?
I can plenty of "cracked free Wi-Fi" networks to choose from from different ISP with all kinds of internet packages. I don't have my own internet subscription, the internet comes without a separate subscription. But you can also find free open Hot-Spots anywhere. The one I tested it on had completely different ISP networks. The two systems are independent of each other and do not communicate with each other. They do not have any internal network connection, or communication. They have two different IP addresses and two different ISPs.
That's not an option.
How about running another test. Delete all torrents from both of your instances. Restart everything just to be sure. Start them both up and run them for a few hours. See if the IP addresses of the instances appear in your firewall. That is, do the entire test with no torrents loaded into BiglyBT on either machine.
That's not an option.
How about running another test. Delete all torrents from both of your instances. Restart everything just to be sure. Start them both up and run them for a few hours. See if the IP addresses of the instances appear in your firewall. That is, do the entire test with no torrents loaded into BiglyBT on either machine.
It was restarted several times and all but one torrent was deleted. If the friends plugin with the chat was active, the leak appeared. If the plugin was turned off, but the current torrent way active the leak disappeared. No torrent used a public connection. If I turn on the plugin, (with the existing torrent) the leaking appears again. I tested it without any torrents and the leak does not appear. The leak can be detected within 10 minutes after starting the system, there is no need to wait for hours. The problem should be occur with the active torrent, but since I turned off the Friends plugin with the chat, the problem has never occurred with the active torrent when the users download it. When the friends plugin are active without torrents (deleted the default torrents too like the plugin torrents) the problem also does not appear (after reinstalled the program). What I noticed if the chat are active in the current anonymous torrent (the pubic chat) are active in the ANONYMOUS torrent with a different DHT what are not the anonymous torrent are using. I think that it is completely ignored by the plugin what Privacy setting are used. And with the current anonymous torrent, it connects to the public chat. If the chat tab are deleted this is not helped.
My point is that what you are saying is a "leak" is not in any way associated with a torrent, it is the general way that BiglyBT works. Every machine that has the public DHT enabled has their public IP available in the DHT. Anyone can trawl around the DHT and enumerate all of those IPs. When you have the "distributed chat" plugin enabled then your public IP is available in any of the public chats that are enabled. By default there are several chats - country, language, dns feed... If you have two machines that share a chat then their IPs can be enumerated. As part of the chat protocol the machines will contact each other.
All this "leaks" is the fact that you share a chat.
It doesn't "leak" anything about what you are downloading.
All you seem to have shown is a correlation between machines running the same chat, NOT a correlation between machines downloading the same torrent.
My point is that what you are saying is a "leak" is not in any way associated with a torrent, it is the general way that BiglyBT works. Every machine that has the public DHT enabled has their public IP available in the DHT. Anyone can trawl around the DHT and enumerate all of those IPs. When you have the "distributed chat" plugin enabled then your public IP is available in any of the public chats that are enabled. By default there are several chats - country, language, dns feed... If you have two machines that share a chat then their IPs can be enumerated. As part of the chat protocol the machines will contact each other.
All this "leaks" is the fact that you share a chat.
It doesn't "leak" anything about what you are downloading.
All you seem to have shown is a correlation between machines running the same chat, NOT a correlation between machines downloading the same torrent.
Yes, but the specific torrent (torrents) has a unique chat. I see that it identifies them based on a unique magnet URL (hash). If this is not anonymized, the user can be associated to the torrent in this way. It's enough if that's all you need to connect bypassing the anonymous network. Within the torrents, there is a chat specifically related to current torrents. And the problem is that it doesn't encrypted tunneled through the I2P network it in the current torrent chat. I didn't even use the chat, I didn't write in it.
The torrent has a unique chat over I2P using the I2P DHT.
The torrent has a unique chat over I2P using the I2P DHT.
Yes, but there are two chats, public and anonymous in a current torrent. And the public non anonymous are have active users in the anonymous torrent. On BiglyBT.exe the firewall listed 50 connections. The given torrent user who seed the current torrent can be found regularly among the many users who use the chat option. The fact that it regularly appears on the firewall so that the user don't even have to write in the chat, just being active is no small thing. This means an authority person is coming who making test downloads with DPI. It is guaranteed to record the user real IP address regularly, when it was disconnected and connected to the network. And this is a huge problem. The solution is if the system detects in a torrent the user are using Anonymous Only mode Then the public chat option is completely disabled the system. For those who use public torrents, this is obviously not a problem, but for those who use anonymous torrents, this is a backdoor. In detail, this is a tracking option.
If you manually select the public chat then you get what you deserve.
You will notice that the Anonymous one is selected by default. The public one is inactive unless you manually decide to "go public".
Prove to me otherwise. Don't tell me how to fix my code. Don't be all dramatic using terms such as "huge problem" and "backdoor" unless you actually have a clue what you're talking about.
For a specific torrent, the chat narrows down the number of users. Who disconnects, connects and when, the chat generates a nickname with public IP. The chat are using IP with user specific ports. Can be filtered by real IP address can be filtered the users behind a torrent using I2P. With a detailed analysis of Internet traffic in expert hands, multiple measurements anonymous users can be accurately identified. Don't even need to write to the chat, writing is a plus. The torrent transfer in anonymous mode does not go through the public network. But it can be narrowed down in detail to a specific torrent, because the user's real IP address is displayed at the same time with specific port. How many people use the given torrent is narrowed down in detail. With appropriate measurements, the real IP address can be accurately associated with anonymous users, so that it can even be used in a court case. Even a more experienced user will not notice anything, if there is no other system from which you can mutually check the connection.
If you manually select the public chat then you get what you deserve.
You will notice that the Anonymous one is selected by default. The public one is inactive unless you manually decide to "go public".
Prove to me otherwise. Don't tell me how to fix my code. Don't be all dramatic using terms such as "huge problem" and "backdoor" unless you actually have a clue what you're talking about.
Enough information has been provided for a good developer to fix this. I see that you know exactly what the problem is here. I can see that the parrying, side-talking is going on. It is not necessary to enable it manually, although it cannot be turned off, it is enabled by default! We both know that this is a serious developer mistake, which wouldn't be a problem if the error was fixed instead of continuous side talk. But I see that there is no intention either.
whatever dude
Almost everyone who was on the network in the open chat was visible from behind the anonymous torrent. You don't have to turn it on intentionally. Those who never wanted to use the option they will turn it on unintentionally. The Friends plugin, which causes the error, is enabled by default. It is not a unique problem what caused by the mistake of the user. All the peers who used the anonymous torrent can be identified in the open chat, clearly filtered to torrent users. It's not that someone turned on a bad option. because it can be shown that it is also active in others. Within the given torrent, the anonymous chat didn't even work, only the public one.
There is no error. You are the error. You switched to the PUBLIC chat on an ANONYMOUS download. You made the choice.
If you use BiglyBT with the DHT or mlDHT enabled (forget the plugin) then your IP address will be available to be discovered by anyone else using BiglyBT or any other client that supports mlDHT (virtually all of them). People can see that you IP address is involved in something or other. If you download a public torrent then people will be able to see that you are downloading that actual torrent.
If you download an I2P torrent then nobody else is able to discover that you are downloading that torrent. They can't correlate your public IP with that torrent. If YOU manually decide to switch to the PUBLIC chat for that download then, obviously, they will be able to see that you are involved in thast download. That's what YOU decided to do when switching to the PUBLIC chat. If you don't switch to is then you can't be correlated to that download. If you decide to use the ANONYMOUS chat for that download they WILL NOT be able to correlate you to that download as the ANONYMOUS chat uses I2P.
Your firewall observations come from the general BiglyBT DHT/chat/whatever, they are not correlatable to the torrent you are downloading.
So I see no problem. End of.
I will however disable the public chat tab for the download, maybe that'll make you less unhappy.
Huge security hole Vuze, BiglyBt 3.6.0.0 are leaking user real IP behind I2P/Tor anonymous mode.
Reproduction: Setup a torrent with only I2P/Tor anonymous mode and delete another torrents. Required to use 2 different internet connection from 2 different computer. Some plugin maybe the "Chat" bypasses the I2P network and connects directly. I detected the issue with Comodo firewall BiglyBT.exe outgoing traffic, both the Seeder and the Downloader, other peers directly connect each other, and see each other real IP. The security hole also affects previous versions!