Man in the middle attack warnings - update connection to be more secure

[therealadityashankar]

trackers are vulnerable to mitm attackes,, if I set-up a "free" tracker, then then, when the connection is supposed to happen I connect the client to my "evil webrtc device" instead of the actual device he wants to, and connect the "evil webrtc device" to the intended recipient, boom, mitm attack

How does one prevent an MITM attack/ensure the data is unread ?

• send spoof data (which could be large occasionally)
• encrypt data FROM THE START, symmetric encryption should be fine if both the target and the owner know the secret key

[subins2000]

MITM is a sure possibility with public WebTorrent trackers like with WebRTC signalling servers. It won't matter with WebTorrent, because the integrity of files are ensured with the info hash which peers know beforehand (are they getting the info hash of the right file they need or did it get tampered by adding a malware is another question).

WebRTC communication by default has encryption, but the signalling servers can be MITMed. With P2PT, the easiest solution would be to use trackers (with wss) that everyone can trust (just like how we trust HTTPS certificate authorities). Communities that support digital freedom can host their own providing it as a service. When such communities host more and more, it'd be easier.

Since public WebTorrent trackers get thousands of info hash every time, it'd be costly to do MITM (which can't tamper WebTorrent files because the info hash is known by the peers beforehand). P2PT also use the same SHA-1 info hash which means it'll be difficult for trackers to distinguish WebTorrent communication and P2PT communication to specifically target P2PT communication and do MITM.

• A good MITM can detect spoof and figure out the real one
• There should be a secure way to share the secret key though which defeats the purpose of a tracker to establish P2P in the first place

[therealadityashankar]

I think the first line of reasoning is correct - we need trackers that everyone can trust the second line of reasoning however - i.e. checking the feasibility of such an attack - and basically the argument that such an attack isn't feasible - is something I'm more skeptical about, - like - lets say you only try to do an mitm attack on info hashes coming from a certain IP address, i.e. it'll be easy to target communications coming from a certain IP address/addresses, which indeed is a vulnerability, like people could check hashes coming from the IPs of journalists

[therealadityashankar]

btw this is really really serious an issue and undermines the whole point of https

[therealadityashankar]

this conversation has kinda made me rethink a little bit about alot of free services like jsdelivr - or rawgit - or other open cdn's as an effective means of compromising user privacy for a huge number of people who would be the knowingly/unknowingly using these sources

like essentially there are a huge number of people who use these services, without realizing that - were an evil party controlling these sources - they would easily be able to provide any arbitrary code to the user

and why webtorrent is super important for the purposes of free services (i.e. cdn's) that are truly secure

[subins2000]

It's feasible, but it's difficult, yes targeting based on IPs can be used too. Even with HTTPS, we have to trust the server & CA authority to act well and not be an attacker. Just like that, in P2PT trust is with the trackers & CA for wss. But if an attacker gain access of a tracker, there is the additional difficulty to distinguish P2PT communication (with random app identifiers) in the large torrent swarm.

With WebTorrent, the integrity of the file is known by parties involved. Nowadays, we can use Subresource integrity for ensuring integrity of content from CDNs.

[therealadityashankar]

@subins2000 I can't believe I didn't think of this, but an alternative solution can be tracker verification, essentially ensure that ALL trackers send the same data (the more trackers the better) over

essentially I may be able to fake the data on my own tracker, but I can't fake the data sent by every tracker

then initiate a public cryptographic key exchange, then re-init the communication via the encrypted channel

I actually need to read more about how the communication scheme works, but I think this is the best solution

[therealadityashankar]

pictorial representation

[therealadityashankar]

How to design a more secure connection via p2pt, for a connection of 2 people: say the 2 people are Rahul and Raj,

"n" is a number > 1, the higher n, the better, I'd recommend keeping n~5, and ensuring the tracking servers are not aware of each other.

1. Rahul and Raj generate public/private keys,
2. Rahul and Raj connect to each other, via p2pt, but create n different connections using n different trackers to the same person, essentially creating n different webrtc connections, to the same person, via different trackers.
3. they share their public keys via all these trackers
4. ensure the public keys sent from all webrtc connections match
5. drop (n-1) webrtc connections
6. all future transactions happen with the exchanged public keys

[subins2000]

Yup, that is a good approach for total secure communication. I did the same thing in Wikipeer, when a wiki article torrent is made by proxy peers, the returned torrent hash is checked, only if n number of peers return the same hash would that torrent be downloaded.

This checking of same data being returned by n number of peers/trackers can be used in trusted communication between both peers and trackers.

[gfodor]

Hey I dig this project - on the subject of secure trackers though one concept I’ve been kicking around for a while is “verified cloud functions.”

Put briefly: you push an AWS lambda that does two things: provides a tracker api, as well as an api you can hit that causes the lambda to do a internal AWS api call over https that queries the lamdba’s metadata and returns you the raw SSL response (signed by amazon.) this metadata would include the eg lambda repository url and version, which could be easily audited. This mechanism takes trust in the cloud provider and uses it to prove what bits are running on the other end.