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

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

  • 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 '15 at 8:05
  • 1
    Just take a look at the specification at w3c.github.io/webrtc-pc – Andi Jun 18 '15 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.