0

Based on this question, I've discovered that the signaling channel for WebRTC must be trusted in order to prevent MITM attacks. This is unfortunate for a P2P use-cases where the signaling channel is some 3rd party device.

One idea I had is to encrypt and authenticate the WebRTC signaling with libsodium box algorithm. This assumes that both peers know each other's public keys.

Would this solve the MITM issue?

Just to add some additional clarification because I frankly don't really know what I'm doing:

I'm using simple-peer which has a simple API for signaling the WebRTC connection. I can create a public pub/sub channel easily using for example signalhub.

Now suppose each peer subscribed to their public key on signalhub. When peerA wants to connect with peerB, peerA uses peerB's public key, boxes the signal from simple-peer with libsodium, and broadcasts the message on signalhub to peerB's public key channel. When peerB receives this signaling message, it can decrypt and authenticate that the message was sent from peerA.

This intuitively feels secure to me. A MITM could attempt to signal to peerB, but wouldn't be able to authenticate as peerA. Also the MITM couldn't decrypt the signal from peerA so they couldn't respond pretending to be peerB either.

As I understand it, once the signaling is complete and the WebRTC connection is established, the P2P channel is end-to-end encrypted so at this point we should be secure.

Chet
  • 101
  • 2

2 Answers2

3

One idea I had is to encrypt the signals with Ed25519. Would this solve the MITM issue?

First, Ed25519 is no encryption, it is a signature algorithm. And no, switching one signature algorithm with another does not magically protect against MITM. The relevant question in the context of MITM attacks is instead who is doing the signature and if this party can be trusted. This question is independent from the actual signature algorithm or encryption algorithm.

After the question was edited:

One idea I had is to encrypt the signals with libsodium box/seal. Would this solve the MITM issue?

Again, the choice of encryption or signature algorithm are not relevant against MITM in this context. What matters instead is authentication which essentially boils down which identities can be trusted in the first place and how an identity can be verified.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I updated the question, I didnt realize that Ed25519 was not an encryption algorithm. – Chet Mar 28 '20 at 23:00
  • @Chet: See my updated answer. In short: changing the encryption algorithm does not solve the actual problem of who can be trusted and thus will not help. – Steffen Ullrich Mar 28 '20 at 23:29
  • Libsodium's box algorithm does encryption and authentication. I'm assuming that each peer knows each others publicKey and boxes the WebRTC signals. I've added additional clarification above. Thanks for the help! – Chet Mar 29 '20 at 03:39
  • *"I'm assuming that each peer knows each others publicKey ..."* - That's a big assumption. Basically you assuming an existing trust relationship where each side has keys or certificates or similar from the other. This way you are simply treating the main issue underlying the MITM problem as solved. You don't explain how it got solved, i.e. how this trust relationship is established in the first place. With this kind of assumption you don't need to add any new algorithms to WebRTC because with this assumption already the existing methods provide protection against MITM. – Steffen Ullrich Mar 29 '20 at 06:11
  • Yeah, well I'm assuming that you can communicate to someone out of band (e.g. send a link on iMessage). But event then, I'm worried that a. malicious signaling server could proxy the requests and MITM the WebRTC connection. Sounds like what I'm doing is fairly secure then. If you want to check it out the code I'm prototyping is [here](https://github.com/ccorcos/p2p-prototype/blob/60c59233e84b19593b714a60d0854de07181f717/src/main/old/app.ts). – Chet Mar 29 '20 at 23:29
0

Good question!

I would look at https://saltyrtc.org, it allows you to do signaling without worrying about trust.

Another thing you could do is supply your own certificates to the RTCPeerConnection (and not use self-signed). I would have to think about it a little more, but if you only you and the other peer had the private key I don't think an attacker could do much? An attacker could inject ICE candidates/record everything, but DTLS and everything below it (Media and DataChannels) should be safe!

Sean DuBois
  • 101
  • 1
  • SaltyRTC looks interesting! Thanks for sharing. Looks like its "beta" though and not actively developed. – Chet Mar 28 '20 at 23:01