Hacker News Reader

Comment by Rhapso | Hacker News Reader

A big problem is that webRTC is highly MITM-able. You have to exchange initial connections using a server. So no party has any way of knowing if you are MITM attacking.

You might be able to do something diffie-helman shaped at the javascript level (hard to ensure it actually works) to show a fingerprint of the shared secret that could be confirmed via outside channels.

But all-in-all this does not offer ANY security over a server because there is no way to show it is not just being stored on a server.

View on HN

Not knowing enough about this, I am genuinely curious if something like zerodb solves this. It was posted yesterday, but it was started by 2 guys, i think one was from morgan stanely, that allow you to securely send and receive data from the db while it is portected in flight. Would this be helpful in the scenario?

This will betray my lack of domain knowledge but it sort of opperates like a double encryption, so basically the data is encrypted maybe then sent, then it is encrypted by a forwarding proxy which also has a priv./pub key. You query for the hash, get the hash, decrypt it, and send it back.

Could you use this as the broker for webrtc? I know that wasn't exactly Nakomoto's BitcoinD paper, but their model seems to make sense, and a lot in this context.

You can do without using a server. https://github.com/cjb/serverless-webrtc

"A STUN server is still used to find out your external IP for NAT-busting."

essentially, now the STUN is the MITM. STUN server lies to both parties about what their IP addresses are and responds with IPs that it controls. Both parties connect to those IPs and the messages are relayed between them.

This is incorrect. Once data starts to flow, DTLS is used to encrypt the connection and verify each peer's identity. If the STUN server attempts to MITM, it will be detected.

Maybe I'm reading your comment wrong (if so, sorry!), but that sounds like a race condition to me.

These are very good points. I believe that adding any real crypto to the JS code to be a doomed path so I probably won't go for that. My only argument right now is couldn't one verify that the IP of the recipient is the same as the address of the expected receiving device (or router) and be somewhat sure it's not MITM?

You can't trust IP addresses for anything. A MITM-ing wifi router can and will pretend to be "all the IP addresses".

that might work well.

I'm a little worried, that because the browser get it's own address from the server there might be a way to build a lie that looks plausible to both users, but I can't think of a way to do that off the top of my head.

The way I would make this work:

- Build a DHT style overlay network of "meet in the middle" servers

- Have a standalone html file, that uses websockets to connect to the network of servers.

- Have both clients generate keys, exchange them via other channels.

- Both users have a shared key, they both lookup the server that hosts the shared key on the DHT network (that actually can be done without leaking the key to every server) then they use that server to exchange NAT-busting messages

Ideally, you would have a lot of different use cases using the same network in such a way that it is hard for a server to figure out what you are using it for, and it is essentially impossible for a server to target MITM a specific pair. What this does leave open is sybil attacking and MITM-ing everything opportunistically. At this point we essentially start to build TOR via websockets and WebRTC and it all breaks down.

This sounds incredibly complicated :) I would definitely use TOR if I believe I'm facing a dedicated and sophisticated threat. For now I have tried to clarify the issues in the FAQ and can only hope that people read it and don't get screwed over by wrong expectations.

How is Tor supposed to help you defend against MitM?

> I believe that adding any real crypto to the JS code to be a doomed path

Mega[1] users JS based crypto and it's been fine

[1]: http://mega.co.nz

Don't hate on js. It is beneath you.

Hating on js and acknowledging that it is currently technically impossible to do any real, secure in-browser crypto engineering with it are two different things.

There are no "good parts" to js browser crypto.

Just encrypt the data and pass the key in the url, like so:

https://bitf.ly/1b4b7ee4fe39312afbfffbe47d831f99#someaeskey

That way, the server never sees the key (it's client-side and fragments don't get sent), but nobody except the recipient can decrypt the data.

that only works if you have a way to assure the JS has not being modified every time the page is ever loaded everywhere. That only works on a content addressed protocol like IPFS

You can trivially ensure that by just downloading the page. These things are usually a single HTML page you can run locally.

The server can silently decide to start sniffing the keys at any time. That isn't security.

We do this on securesha.re. Yes, you can't be sure the client hasn't changed the JS - I'm going to start putting md5s in the script tags but it's up to the client to check they haven't changed. However, the client is open source [1], so you could always run your own client.

1. https://github.com/STRML/securesha.re-client/

Reply on news.ycombinator.com