1

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?

WebRTC

Improve this question
4
  • This is a question for the WebRTC devs.
    – schroeder ♦
    Commented Mar 30, 2015 at 23:12
  • 1
    Can you provide the source to the statement that certificates are self-signed?
    – schroeder ♦
    Commented 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
    Commented 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
    Commented Mar 31, 2015 at 12:27

2 Answers 2

Reset to default
3

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.

Improve this answer
2
  • 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
    Commented Jun 17, 2015 at 8:05
  • 1
    Just take a look at the specification at w3c.github.io/webrtc-pc
    – Andi
    Commented Jun 18, 2015 at 9:09
0

@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.

Improve this answer

You must log in to answer this question.

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