7 comments on “WebRTC and Man in the Middle Attacks

  1. Alan,
    You can get the audio result you want in firefox by using AudioContexts to pipe the
    audio from one peer-connection to another.

    I’ve been working on solving this issue and have come up with a nice standards compliant way – which I’ve filed a patent on – https://yopet.us demos it in a way that avoids needing to read long (or short) hex strings to each other.

    Happy to catch up if you want more info.


    • Hey Tim,

      Thanks for the pointer on Firefox – I’ll give AudioContexts a try.

      Yopet is cool! Very handy for talking to your “late” parrot. I’m presuming that it is essentially a cached shared secret between the two browsers. This allows you to authenticate the other browser for all future calls, which is useful. However, this doesn’t help if you and I haven’t talked before – we have no shared secret and hence no protection against MitM. Now ZRTP also has this feature, so that once the SAS has been verified, a shared secret is cached which means you don’t need to check the SAS again as long as the caches remain. Your approach of using the screen to set the shared secret is very cool!

      Of course, ZRTP isn’t the only approach, but it does solve the MitM problem without trusting any third party or service. And ZRTP can use words instead of hex digits, so the users only need to compare two words.

      – Alan –

      • The innovation is in the selection of the shared token, which isn’t a secret by the way, and the way we use it.
        We not only have to have talked before, but the way YoPet works the two devices have been in physical proximity to form the initial pairing visually. (other methods are possible of course). From then on the cached token maintains the pairing with just a few lines of javascript.

  2. I have a working webrtc data-channel MiTM demo online right now – http://blog.erbbysam.com/?p=149 (be careful to follow the directions regarding usernames).
    It’s unclear to me why ZRTP is the answer here. You still need to verify SAS strings (on first connection), right? IdP’s could be a lot more transparent to the end user (if I’m not mistaken) & increases MiTM complexity to include compromising IdP’s (still not as secure as SAS strings, but much more secure than what exists now).

    If ZRTP SAS strings exchanged out-of-band are the solution here, why not just exchange DTLS fingerprints?

    Regarding identity providers – what are your concerns?

    • Hi Samuel,

      I’ll take a look at your link. This post isn’t about how ZRTP protects against this attack, so it is missing all the details you crave. ZRTP can detect the DTLS MitM attack immediately by checking the DTLS fingerprints, without the users checking the SAS, if the attacker is not also doing a MitM attack on ZRTP. If the attacker is also doing a MitM attack on ZRTP, then comparing the SAS will detect this very determined MitM as well.

      Identity Provider is also another topic. My two main high level concerns are: 1. We don’t have it yet, either in browsers or providers, and 2. It is a third-party who has to be trusted, and could be compromised or compelled to lie. Using a peer-to-peer approach such as ZRTP provides MitM protection without trusting or relying on any third party.

      – Alan –

  3. Pingback: RealTimeWeekly | RealTimeWeekly #85

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.