From what I could tell, certificates are self-signed. When A wants to call B, after they finish relaying data to server, they initiate communication with each other. Certificates are self-signed, therefore there is no problem in switching them up. Is there some mechanism to make sure that if C is on the same wifi as B, why he could not send to A and B the certificate of C and intercept A and B's certificate then proxying the whole conversation?

Is there some hash that is sent from A to B and vice-versa via the authenticating server that can then be validated against the certificates?


  • This is a question for the WebRTC devs.
    – schroeder
    Mar 30, 2015 at 23:12
  • 1
    Can you provide the source to the statement that certificates are self-signed?
    – schroeder
    Mar 30, 2015 at 23:16
  • According to the following document: ietf.org/proceedings/82/slides/rtcweb-13.pdf The parties involved identities should be verified with identity provider. Do you have a specific implementation that is in use you are looking at or just some simple example?
    – Goblinlord
    Mar 31, 2015 at 6:06
  • At the moment i have been tinkering around with: [link]webrtc-chat-demo.herokuapp.com What i have done: I found a program that allows me to modify WebRTC data before receive and after send. I have been trying to replace one certificate with an other. Since they are self signed I thought it should work, as there is no way of validating the issuing party of the certificate. None the less, this failed. I am trying to understand if this is something that is delt with by DTLS or WebRTC. Any ideas?
    – ben f
    Mar 31, 2015 at 12:27

2 Answers 2


The fingerprint of the DTLS self-signed certificate is exchanged through the signaling channel with the offer-SDP and answer-SDP.

During the DTLS handshake a session key is established and the fingerprint of the endpoint certificates is compared to the fingerprint exchanged in the signaling phase. Therefore, the certificate cannot be replaced without the endpoints noticing.

The signaling server needs to be trusted.

  • first of all thank you very very much for the answer, this explains some things. one last thing, can you reference me where did you find this information?
    – ben f
    Jun 17, 2015 at 8:05
  • 1
    Just take a look at the specification at w3c.github.io/webrtc-pc
    – Andi
    Jun 18, 2015 at 9:09

@Andis answer explains it quite well and suggests that in the end the signaling server could MITM the connection. This is true and a practical attack with a compromised signaling server already succeeded.

However I'd like to add one exception: If the users use a online service which can authenticate them WebRTC connections can be made MITM-resistant. These online services can include OpenID, BrowserID, Federated GoogleLogin, Facebook Connect, OAuth, WebFinger, DNSSEC or Facebook chat (this are all examples mentioned in the specification) and in WebRTC they may act as "Identity Providers". If the users are authenticated with these Identity Providers they can be sure that the signaling server is not MITM their connection, because compatible "Identity Providers" link the fingerprint of user keys to the user.

You must log in to answer this question.

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