We are implementing an open source software package (copay, a multisig bitcoin wallet), that uses peerJS, which uses webRTC to allow peer-to-peer communication between browsers.

peerJS (and webRTC) use a signaling server to help the peers establish the p2p channel. My question is: Do we need to trust that signaling server? Could that server compromise the p2p channel by doing a man-in-the-middle attack?

thanks a lot. Our project home is: https://github.com/bitpay/copay

  • 1
    Some pointers from my (failed) attempt to answer this: WebRTC appears to require DTLS. The spec apparently allows fingerprint authentication and also PKI.
    – derobert
    Apr 29, 2014 at 19:46

4 Answers 4


The answer is dependent on what "signalling server" you refer to.

WebRTC is MITM-secure against untrusted relayservers, STUN and TURN servers. Those servers only help the clients to set up a p2p connection at all.

However, the channel through which SDP is done needs to be trusted.

Unlike the relayserver, SDP carries no weight, and consists only of some strings sent by the clients for the initialisation of a connection. Those are accessible to javascript, and can be sent any way (HTTP, websockets, email) between the clients.

Therefore you should use a trusted channel for doing the SDP.

The SDP exchange carries a a=fingerprint: named hash, that authenticates the payload-bearing p2p DTLS connection to the other client. RFD 5763 contains a good description of that connection between DTLS and SDP.

You could reduce the content that needs to be trusted to this hash, but unless it serves no further purpose you are better off doing the whole SDP over a trusted channel, as you have less complexity.


in addition to your own awnser, any connection (http, p2p..) is never fully secure, the trick is to have such a security, its too hard to get into, since the certificates are self-signed, doesnt directly mean they are unsafer, focussing on a better cryptography (for the enviorment itself) and a good SSL certificate is better, maybe you want to take a look at this: https://www.globalsign.com/ssl-information-center/dangers-of-self-signed-certificates.html

after all, the REAL insecurity in any web application, is the user :)


The answer is No. webRTC clients generate self signed certificates. It has been proposed to use an external ID provider, but not yet implemented.


Identity and Authentication The DTLS handshake performed between two WebRTC clients relies on self-signed certificates. As a result, the certificates themselves cannot be used to authenticate the peer, as there is no explicit chain of trust (see “Chain of Trust and Certificate Authorities”) to verify. If required, the WebRTC application must perform its own authentication and identity verification of the participating peers:

A web application can use its existing identity verification system (e.g., require login to authenticate the user) prior to setting up the WebRTC session. Alternatively, each participating peer can specify its "identity provider" when generating the SDP offer/answer. Then, when the SDP message is received, the opposing peer can contact the specified identity provider to verify the received certificate. The latter "identity provider" mechanism is still under active discussion and development in the W3C WebRTC working group. Consult the specification and the mailing list for the latest implementation status.

Also relevant: http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf


https notes = probably not relevant, but maybe useful?!

If the user allows Adobe Flash then it is possible: http://www.scmagazine.com/researchers-detect-ssl-mitm-attacks-method-implemented-by-facebook/article/346994/

I think that for Chrome the answer is that you can't even do it from JS even within an extension: https://code.google.com/p/chromium/issues/detail?id=107793

In Firefox I think it is only possible within a XUL extension see link in this https://stackoverflow.com/questions/18689724/get-fingerprint-of-current-pages-ssl-certificate-in-a-chrome-extension e.g. see https://addons.mozilla.org/en-us/firefox/addon/certificate-patrol/

Probably irrelevant: there is a JavaScript cryptographic tools library: https://github.com/digitalbazaar/forge/blob/master/README.md Also probably irrelevant: https://www.rfc-editor.org/rfc/rfc6797 or http://dev.chromium.org/sts

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .