答案取决于您所指的“信令服务器”。

WebRTC 对不受信任的中继服务器、STUN和TURN服务器是 MITM 安全的。这些服务器只帮助客户端建立 p2p 连接。

但是，需要信任完成SDP的渠道。

与中继服务器不同，SDP没有权重，仅包含客户端为初始化连接而发送的一些字符串。这些可以通过 javascript 访问，并且可以在客户端之间以任何方式（HTTP、websockets、电子邮件）发送。

因此，您应该使用受信任的渠道来执行 SDP。

SDP 交换带有一个a=fingerprint:命名散列，用于验证到另一个客户端的承载负载的 p2p DTLS 连接。RFD 5763很好地描述了 DTLS 和 SDP 之间的连接。

您可以将需要信任的内容减少到此散列，但除非它没有进一步的用途，否则最好通过受信任的通道执行整个SDP，因为您的复杂性更低。

除了您自己的 awnser 之外，任何连接（http、p2p ..）都永远不会完全安全，诀窍是拥有这样的安全性，很难进入，因为证书是自签名的，并不直接意味着它们是更不安全，专注于更好的密码学（对于环境本身）和一个好的 SSL 证书更好，也许你想看看这个：https ://www.globalsign.com/ssl-information-center/dangers-of -自签名证书.html

毕竟，任何 Web 应用程序中真正的不安全感是用户 :)

答案是否定的。webRTC 客户端会生成自签名证书。已提议使用外部 ID 提供程序，但尚未实施。

http://chimera.labs.oreilly.com/books/1230000000545/ch18.html#_secure_communication_with_dtls

身份和身份验证 两个 WebRTC 客户端之间执行的 DTLS 握手依赖于自签名证书。因此，证书本身不能用于验证对等方，因为没有明确的信任链（请参阅“信任链和证书颁发机构”）进行验证。如果需要，WebRTC 应用程序必须对参与的对等方执行自己的身份验证和身份验证：

Web 应用程序可以在设置 WebRTC 会话之前使用其现有的身份验证系统（例如，需要登录来验证用户身份）。或者，每个参与对等方可以在生成 SDP 提议/答案时指定其“身份提供者”。然后，当收到 SDP 消息时，对端可以联系指定的身份提供者来验证收到的证书。后一种“身份提供者”机制仍在 W3C WebRTC 工作组中积极讨论和开发。查阅规范和邮件列表以了解最新的实施状态。

也相关： http ://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf

https 笔记 = 可能不相关，但可能有用？！

如果用户允许使用 Adob​​e Flash，那么它是可能的：http ://www.scmagazine.com/researchers-detect-ssl-mitm-attacks-method-implemented-by-facebook/article/346994/

我认为对于 Chrome 来说，答案是即使在扩展程序中你也不能从 JS 做到这一点：https ://code.google.com/p/chromium/issues/detail?id=107793

在 Firefox 中，我认为只能在 XUL 扩展中查看链接https://stackoverflow.com/questions/18689724/get-fingerprint-of-current-pages-ssl-certificate-in-a-chrome-extension例如见https://addons.mozilla.org/en-us/firefox/addon/certificate-patrol/

可能无关：有一个 JavaScript 加密工具库：https ://github.com/digitalbazaar/forge/blob/master/README.md 也可能无关：https ://www.rfc-editor.org/rfc/rfc6797或http://dev.chromium.org/sts