3 ms·

What I haven't found is a peer-to-peer way of mutually-authenticating identity for a WebRTC connection. Perhaps it is possible to build it out of this: https:

What I haven't found is a peer-to-peer way of mutually-authenticating identity for a WebRTC connection. Perhaps it is possible to build it out of this: https://w3c.github.io/webrtc-identity/ https://w3c.github.io/webrtc-identity/ but it seems that the assumption is that a remote domain acts as a trusted match-maker. Ideally two peers could use a pre-shared secret or an offline-signed message to authenticate instead. If this were possible, then two browsers could act as a basic serverless VPN, layering an encrypted link over the WebRTC data channel which is safe even against an SSL-decrypting MitM.

yodon 8y ago
Key distribution is generally the weakest link in any public use crypto system, both because it's a fundamentally hard problem and because people are the weakest link. If you built a "peer to peer" crypto system based around offline token sharing for identity, 99% of your users would email or text message their secrets to each other and more importantly 99+% of your users would accept a token they received from the other party that way.
kodablah 8y ago
> Ideally two peers could use a pre-shared secret or an offline-signed message to authenticate instead You can easily share offers and answers that are encrypted offline. It's how you share (i.e. signaling) that's the problem. I used gun.js the other day, and I used a js nacl impl to encrypt the offer/answer each way[0]. As the ipfs js dht gets better you'll be able to use that. Where you'll need a trusted third party is if you need a turn server due to firewall/nat issues (some say approx a quarter of net users). 0 - https://myscreen.live/faq.html#q-how-it-works-detail https://myscreen.live/faq.html#q-how-it-works-detail
- dane-pgp 8y ago
  That's incredible, and extremely close to the hypothetical use case I was imagining, which I thought was impossible to solve. Could you adapt that technology into a system for allowing a computer in one location to browse the web using the (relatively unrestricted) network connection of a computer in another location? I'm thinking of times when you're away from home (where your PC is running) and stuck using a web browser on another PC that has an aggressive filtering and/or monitoring policy. That's why in my threat model I imagined that there was a MitM that effectively operates a trusted CA. The difference between screen sharing and being a web proxy is presumably that the "sending" browser is also accepting navigation requests (from the "receiving" browser) which control the URL and scrolling/clicking of an iframe in the page that hosts the web app itself. I suppose that capturing the clicks on hyperlinks would be the hardest part, unless you could do some clever conversion between pixel locations and DOM elements.
- SahAssar 8y ago
  The TURN server doesn't need to be trusted as it never receives keys or sees unencrypted traffic, it only forwards encrypted traffic. It can still track metadata (who you're transferring data to), but it doesn't need to be trusted any more than your ISP.

yodon 8y ago

Key distribution is generally the weakest link in any public use crypto system, both because it's a fundamentally hard problem and because people are the weakest link. If you built a "peer to peer" crypto system based around offline token sharing for identity, 99% of your users would email or text message their secrets to each other and more importantly 99+% of your users would accept a token they received from the other party that way.

kodablah 8y ago

> Ideally two peers could use a pre-shared secret or an offline-signed message to authenticate instead You can easily share offers and answers that are encrypted offline. It's how you share (i.e. signaling) that's the problem. I used gun.js the other day, and I used a js nacl impl to encrypt the offer/answer each way[0]. As the ipfs js dht gets better you'll be able to use that. Where you'll need a trusted third party is if you need a turn server due to firewall/nat issues (some say approx a quarter of net users). 0 - https://myscreen.live/faq.html#q-how-it-works-detail https://myscreen.live/faq.html#q-how-it-works-detail

dane-pgp 8y ago
That's incredible, and extremely close to the hypothetical use case I was imagining, which I thought was impossible to solve. Could you adapt that technology into a system for allowing a computer in one location to browse the web using the (relatively unrestricted) network connection of a computer in another location? I'm thinking of times when you're away from home (where your PC is running) and stuck using a web browser on another PC that has an aggressive filtering and/or monitoring policy. That's why in my threat model I imagined that there was a MitM that effectively operates a trusted CA. The difference between screen sharing and being a web proxy is presumably that the "sending" browser is also accepting navigation requests (from the "receiving" browser) which control the URL and scrolling/clicking of an iframe in the page that hosts the web app itself. I suppose that capturing the clicks on hyperlinks would be the hardest part, unless you could do some clever conversion between pixel locations and DOM elements.
SahAssar 8y ago
The TURN server doesn't need to be trusted as it never receives keys or sees unencrypted traffic, it only forwards encrypted traffic. It can still track metadata (who you're transferring data to), but it doesn't need to be trusted any more than your ISP.