Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the tor network as transport network - for hole punching and protecting privacy #3235

Open
ole-tange opened this issue Mar 16, 2021 · 8 comments

Comments

@ole-tange
Copy link

ole-tange commented Mar 16, 2021

"Welcome. LBRY takes privacy and choice seriously."

This is the very first message that is shown when LBRY is first installed.

Privacy is hard to do right. A single bug or design flaw and your program leaks private data.

I would love if LBRY protected privacy so well, that even Burmese democracy activists could use this for activism without fear.

In Burma there is one ISP. And we can assume this ISP also has the resources to setup thousands of LBRY accounts and download every single LBRY video.

If this ISP with reasonable confidence can see which movie the activists are watching, it can mean prison time for the activists.

Does LBRY leak private data?

A simple ngrep will show that searches and requesting videos is sent in clear text:

T 192.168.1.33:36162 -> 51.89.41.46:50001 [AP] #454
  {"jsonrpc": "2.0", "method": "blockchain.claimtrie.resolve", "id": 108, "params": ["lbry://@PROSA"]}.                                           

T 192.168.1.33:36162 -> 51.89.41.46:50001 [AP] #9430
  {"jsonrpc": "2.0", "method": "blockchain.claimtrie.resolve", "id": 117, "params": ["lbry://@PROSA#c/Vacciner-dit-viftekort#3"]}.                

This is bad, because that can be seen by the ISP.

ngrep also reveals which blobs the activist requests:

T 192.168.1.33:45450 -> 51.210.220.149:5567 [AP] #95
  {"requested_blobs": ["77416e376ab458b77e5d9db01634ecb647c8ad6d20abc8f4a00abe196905fd15b0aef1447b388c9144cea0a4a9890a9a"], "lbrycrd_address": true, "blob_data_payment_rate": 0.0, "requested_blob": "77416e376ab458b77e5d9db01634ecb647c8ad6d20abc8f4a00abe196905fd15b0aef1447b388c9144cea0a4a9890a9a"}

If an attacker has downloaded all videos, he will also have a blob file called: 77416e376ab458b77e5d9db01634ecb647c8ad6d20abc8f4a00abe196905fd15b0aef1447b388c9144cea0a4a9890a9a and he will know which video it came from. Even if the content of the blob is encrypted.

This is bad, because we can assume the ISP has the resources to download all videos and record their blobfile names. Thus the ISP can identify which video the activist is watching.

Even if the whole transport is encrypted, the sender would be able to see which blob (and thus which video) a given IP-address requests. If the ISP had all blobs for all videos and many accounts, chances are the activists will request at least one blob from the ISP.

This is bad because the ISP knows who is using the IP-address.

On top of this the ISP can throttle access to LBRY nodes outside Burma and thus increase the chances of one of their accounts being used as blob supplier.

So it is pretty clear that LBRY is leaking private data.

Tor

Tor is best known for Tor-browser. This makes it possible to access web pages that are censored in your home country. It also makes it hard for your ISP to see what you are doing.

Tor bandwidth

You may have experienced Tor-browser as slow. This is mostly due to the final hop, where your traffic is sent through an exit node. There are few of these and they are often overloaded.

But if your tor traffic never leaves the tor network, there is plenty of bandwidth.

Use Tor Hidden Services

Two tor nodes can contact each other using Hidden Services. This traffic stays in the tor network and never touches an exit node.

Data from the sender is bounced around 3 times before hitting a rendevous point, after which data is bounced around 3 more times before reaching the receiver.This sounds slow, but in practice I experience a lag of around 500 ms: It is perfectly acceptable for running SSH through. By using multiple connections (e.g. by downloading multiple blobs in parallel) a throughput of 10 Mbps is no problem.

Setting up a hidden service is not hard: It is literally 2 lines in a config file. E.g. for ssh:

HiddenServiceDir /home/tor/hidden_service/
HiddenServicePort 22 127.0.0.1:22

Instead of accessing hosts like 12.189.124.107 LBRY will accessing hosts like imuqkh75wp2chf5av5esqyyzgdmn4in763vs7ilu2rikbcek6e7qfsqd.onion

No need to deal with hole punching

Another great feature of Tor Hidden Services is that you do not need to deal with port forwarding and hole punching. There is no problem in having multiple machines behind the same NAT wall, and two machines behind NAT walls can access each other.

If your ISP does not block access to Tor, you can be part of the network. And Tor excels in getting around ISPs that try to block Tor.

Distributing Tor with LBRY

Tor is free software, so you are allowed to distribute Tor along with LBRY. So there is no need for LBRY users also having to set up Tor.

Summary

Using the tor networks as transport for LBRY solves several problems:

  • It makes it harder to leak private data onto the physical network.
  • It makes it harder to see who is using LBRY.
  • It solves the hole punching problem.

On top of this you will be helping Tor: Tor is only safe to use if there are legitimate uses for Tor. If the only ones using Tor in Burma are democracy activists, it makes it easier for the government to identify those. But if millions of Burmese use it, then using Tor in itself will not raise a red flag. And it will be harder for Burmese government to shut down tor, because many users will complain. Just like the Burmese government cannot shut down the internet without causing massive problems for the legitimate internet use.

I hope LBRY will consider using Tor as the transport network.

@tzarebczan
Copy link
Contributor

Thanks for the issue. We have these feature requests filed under these issues. I don't think we'll be supporting tor directly as it won't work nicely with the P2P aspects, and the data transferred between clients is already encrypted.
hole punching through some networks (only required for hosting mainly)#2598 / #2429

SSL on wallet server (to solve the clear text issue you mentioned) #2315

@ole-tange
Copy link
Author

won't work nicely with the P2P aspects

How can you say that? Would it not be peer-to-peer if every LBRY node was a Tor client, too?

None of the tickets you refer seem to address:

Even if the transport is encrypted, the sender would be able to see which blob (and thus which video) a given IP-address requests. If the ISP had all blobs for all videos and many accounts, chances are the activists will request at least one blob from the ISP.

This is bad because the ISP knows who is using the IP-address.

Encrypting the blobs does not help if the attacker has the key, too. It only gives a false sense of security.

@kauffj kauffj reopened this Mar 16, 2021
@kauffj
Copy link
Member

kauffj commented Mar 16, 2021

I'm re-opening this because I think there are valid improvements outside the scope of already filed tickets. This should probably be processed by @lyoshenka or @eukreign.

@peepo5
Copy link

peepo5 commented Jul 4, 2021

LBRY team and Odysee have been making a well designed platform, but these issues will probably need to be picked apart more before it can be recommended in a privacy-related manner.

Also there are concerns with their cryptocurrency:
You can buy it straight from them with car or crypto swap, but is incredibly hard to get out as of now for the average user.
I think only bisq or centralized exchanges can be used (They used to have a direct swap out).
https://lbry.com/faq/exchanges

image

In addition, odysee uses trackers natively on their site when privacy-respecting alternatives could be used.
image

@kodxana
Copy link
Contributor

kodxana commented Dec 2, 2021

What I would sugest is using I2P network instead of Tor. I2P is more optimize towards P2P aspect of LBRY ( blob exchange over UDP) . So with integrated SAM (https://geti2p.net/pl/docs/api/samv3) it would be possible to auto create tunnels required for blob seeding (I2P allows UDP and torrenting). What issues are:

  1. We need SDK DHT nodes with i2p adress
  2. HUB servers would need to allow getting requests over i2p (run hub in mix network clearnet and i2p or only i2p)

@ole-tange
Copy link
Author

What I would sugest is using I2P network instead of Tor.

I2P would also be an option.

Personally, though, I find the bullet list ("Benefits of Tor over I2P" on https://geti2p.net/en/comparison/tor) would weigh in favor of Tor: e.g. "Has already solved some scaling issues I2P has yet to address". And in general: Tor has a proven track record, which will likely lead to fewer surprises.

@ole-tange
Copy link
Author

ole-tange commented Dec 5, 2021

LBRY team and Odysee have been making a well designed platform, but these issues will probably need to be picked apart more before it can be recommended in a privacy-related manner.

AFAICT this only applies to Odysee and not LBRY - thus irellevant for this ticket which is about LBRY.

@peepo5
Copy link

peepo5 commented Dec 6, 2021

How about using the lokinet instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants