WebRTC 安全吗？安全与隐私全解析（2026）

作者：Tsahi Levent-Levi
原文：https://bloggeek.me/is-webrtc-safe/

视频通话与 WebRTC 正日益流行，并走到我们生活的中心，在有了 AI 智能体之后，某种程度上更是如此。让我们看看 WebRTC 是如何处理安全（与隐私）问题的。

本文想梳理一下 WebRTC 为何如此安全的背后逻辑，同时谈谈 WebRTC 中一些尚未解决的安全与隐私问题。

关键要点

• WebRTC 是当今最安全的语音与视频通话技术，这一点在 2026 年依然成立
• WebRTC 中的所有媒体和数据在设计上都是加密的，不存在明文发送的方式
• 媒体服务器会破坏端到端加密，除非你加上 SFrame 并把密钥与服务器隔离
• 通话中的 AI 功能，如转录、摘要和翻译，大多运行在云端，与端到端加密并不相容
• WebRTC 只负责协议层的安全，身份、日志、TURN 凭证和房间链接则取决于你的应用

WebRTC 的安全机制

WebRTC 从设计之初就把安全放在核心位置

在深入讨论 WebRTC 带来的那些更”软性”的安全收益之前，先理解 WebRTC 本质上为何安全很重要。

下图展示了 WebRTC 协议的栈结构（取自优秀的《高性能浏览器网络》一书）。我擅自标注了其中与安全相关的部分。

信令

先从左侧说起。那部分其实并不属于 WebRTC 本身，而是浏览器中进行的 WebRTC 信令。WebRTC 使用 TLS 会话或 QUIC 作为其信令传输，两者本质上都是加密的。在 WebRTC 中，其他非加密信令的途径实际上并不存在。理论上它们或许能用，但今天的浏览器不会把摄像头和麦克风权限交给一个 HTTP 页面——如果你的网页用的是 HTTP 而非 HTTPS，你就无法有效使用 WebRTC。在浏览器实现中不加密信令、却要把 WebRTC 部署到生产环境，这不是一个现实的选项。好消息是，这本来就是当今网页的标准做法。

WebRTC “强制”你加密信令。WebRTC 范围之外的部分是认证、授权和身份管理。这些领域你可以随意处理，但务必做点什么，别让它们对恶作剧者或更糟的人完全敞开。

对于移动端、桌面或嵌入式上的原生应用，你想怎么做都行。但思路必须一致，信令加密是强制要求。

媒体

归根结底，WebRTC 是一个媒体栈，也就是图的右侧。

WebRTC 会加密经由它发送的数据，没有别的可能。

从更技术的角度看，WebRTC 通过 SRTP（安全 RTP）发送实时音视频。可用的加密算法（cipher）有多种。默认算法可能不同，媒体服务器也可以强制使用更强的加密。随着时间推移，可以预期规范中的加密套件会持续更新，更老旧、更易受攻击的套件会被弃用并移除。

规范文本对于 WebRTC 通信安全中哪些是必须实现的、哪些是完全禁止实现的，写得非常明确。

数据通道通过基于 DTLS 的 SCTP 发送，且始终加密，与语音和视频一样。

为 SRTP 会话获取共享密钥材料的初始密钥交换使用 DTLS-SRTP，这一机制在协商共享密钥材料时，不让数据窃听者轻易推导出该密钥。而且为了保险起见，规范还禁止使用 SDES，也就是禁止在一条被认为是安全的传输通道里明文发送密钥。对于开发者所使用的信令通道，WebRTC 采取的是零信任的立场。

规范文本对 WebRTC 中安全考量的严肃程度表述得非常清楚：

实现必须支持 SRTP。实现必须支持 DTLS 和 DTLS-SRTP 用于 SRTP 密钥协商。实现必须支持基于 DTLS 的 SCTP。

所有媒体通道必须通过 SRTP 和 SRTCP 保护。媒体流量不得通过明文（未加密）的 RTP 或 RTCP 发送；也就是说，实现不得协商使用 NULL 加密模式的加密套件。每个媒体通道都必须提供 DTLS-SRTP。WebRTC 实现不得提供 SDP Security Descriptions，也不得在对方提供时选择它。不得使用 SRTP MKI。

所有数据通道必须通过 DTLS 保护。

DTLS-SRTP 会在 SDP 中交换自签名、自动生成证书的指纹，随后在连接建立时与 DTLS 握手进行比对。用于媒体加密的密钥在握手过程中派生，且只有参与的两方知晓。这仅留下了一个缺口：信令服务器发起的主动中间人攻击。

如果你使用了媒体服务器，那么该媒体服务器很可能会终止加密，从而成为媒体路径上的一个可信实体。

使用媒体服务器时的端到端加密

端到端加密（简称 E2EE）意味着除参与者之外，任何人都无法”偷听”发生的事情。对 WebRTC 来说，这同时涵盖信令与媒体。

对信令而言，它意味着两件事。第一，你通过信令发送的任何敏感内容（例如聊天消息）必须在参与者之间加密，使信令服务器无法读取。第二，参与者需要在不被服务器看到的情况下交换媒体加密密钥，比如使用 MLS 这样的密钥交换机制。两者都在 WebRTC 的范围之外，但都需要你自己处理。

对媒体而言，我们可以看三种主流架构：mesh、MCU 和 SFU。

对 mesh（P2P）而言，无需担心。WebRTC 在实体之间是端到端加密的，而中间可能存在的 TURN 服务器本来也不知道媒体的加密密钥。

MCU 必须能访问媒体。由于它是混流型媒体服务器，需要能听到参与者的音频、看到视频，才能把它们混合并编码给其他参与者。因此 MCU 破坏了 E2EE 的承诺。

SFU 则比较微妙。其朴素实现会破坏 E2EE 承诺。不过，有一条路可以解决：实现 SFrame，让参与者在应用层于发送前加密、在解码前解密媒体。这样，只要参与者在交换密钥时不让 SFU 知晓，SFU 也就无法访问媒体。

虽然 E2EE 很好，但请记住，它会影响录制、直播、转录和会议摘要等功能的提供。

无论如何，如果你把服务宣传为端到端加密，务必检查我那份 WebRTC 安全清单中的第 7 条规则。

摄像头与麦克风访问

要访问麦克风和摄像头，应用最终需要向用户申请权限。

该权限不是自动的，也无法被设为自动（除非你自己编译代码并构建自己的原生应用）。

如今的浏览器让用户对权限持续时间有更多控制。例如，Chrome 提供”仅此次允许”选项：权限只在当前访问中有效，对于摄像头和麦克风，只要页面还在使用它们就持续有效。其他浏览器对是否记住用户选择各有各的做法。

最后这一点把责任放到了你身上。只要你的应用仍持有摄像头或麦克风，权限就仍然有效，摄像头指示灯就仍然亮着。通话一结束就应立即释放这些设备。这是我那份安全清单中的第 6 条规则。

申请权限的弹窗同样不可由应用编辑或配置。这样做的目的是阻止任何别有用心的开发者和网站通过修改这些对话框来欺骗用户。

屏幕共享

所有浏览器都会在共享屏幕前向用户请求权限。

所有浏览器都会为此使用各自专门的对话框。

所有浏览器都会每次重新询问，不会记住用户上一次关于屏幕共享的选择。

所有浏览器都会有自己不可被应用开发者覆盖的浮动停止共享框。

在某些情况下（例如 Chrome），应用可以对共享内容有稍多一些控制：默认向用户建议的是全屏、某个窗口还是某个浏览器标签；是采集某个区域还是某个 DOM 元素；是否同时采集该窗口或设备的音频；等等。

本地 IP 与隐私

多年来，WebRTC 一直”被指控”存在严重的隐私泄露（这与安全不同，但有时会被混为一谈）：WebRTC 会通过 JavaScript 暴露浏览器的本地 IP 地址，并把它经信令通道发送出去。在注重隐私的人看来，这是件坏事。

正因如此，WebRTC 在适用的场景下引入了对本地 IP 地址的 mDNS 支持，使得在协商阶段既能发现本地网络中的用户，又不必向任何人暴露本地 IP 地址。

开源、标准化与 WebRTC 安全

上一节已经提到 WebRTC 的一个重要方面：它既是开源的，也是标准化的。

如果你关注我几年了，可能知道我对标准化通常怎么看：

我过去在 WebRTC 出现之前也参与过一些标准化工作，所以我知道这套流程怎么运作。它是一个漫长而艰苦的过程，尤其是与”自己单干、做自有方案”这个替代选项相比。

WebRTC 花了很长时间才成熟到获得”推荐标准”（Recommendation）地位（即正式标准化）。从 2011 年一直等到 2021 年。早点会更好，但这已是覆水难收的往事。

而关键在于：在安全（与隐私）方面，我更倾向于标准化的”委员会式设计”与开源开放，而不是专有路线。

为什么？因为做这些决策的人对安全懂得不止一两点，而且他们极其在意这件事。相比单一公司，他们受商业需求的牵制要少得多。

WebRTC 还要在网页浏览器中运行。而浏览器是安全、黑客攻击与恶意软件方面最具挑战性的环境之一。

WebRTC 并非一切都尽善尽美，但总在向前推进。这就引出 WebRTC 安全的下一个方面。

站在浏览器巨人的肩膀上

浏览器在设计上是安全的。它们是当今通往互联网与世界的窗口。因此，它们一直在持续努力提升自身安全性，无论是否与 WebRTC 相关。

在考虑 WebRTC 的浏览器安全时，有几件事值得你留意：

• 浏览器更新频繁且自动。现在很多浏览器每两周就更新一次。仅凭这一点，就让 WebRTC 成为最安全的 VoIP 方案。它也会让厂商不得不跟上浏览器的节奏，从而促使其自身更新更平滑、更频繁。

• 依赖浏览器做 WebRTC，意味着你把信任寄托在浏览器的安全措施与最佳实践上，而这些远比 VoIP 的替代方案严格得多。这使 WebRTC 更安全。

• 浏览器厂商所做工作的一个例子，是 2018 年的 WebRTC 模糊测试（fuzzing）行动：对消息进行模糊测试以排查安全漏洞（确实找到了漏洞并已修复）。

• 在我们这个智能体化 AI 时代，我们也看到 WebRTC 实现中被发现并修复的安全问题越来越多，这得益于 Google 与整个行业在加固浏览器安全方面的投入。

换个角度想：浏览器的目标是十亿级用户。在这样的规模下，它们处理与应对的安全威胁远比你在一项服务中遇到的要多得多。WebRTC 在安全机制及其受到的审视程度上，正是借用了这种规模效应。

专有安全是一团乱麻（在视频会议领域）​

如果你对 WebRTC 安全的疑虑，源自想转而选择专有方案，那么要知道：在视频会议这个领域，安全状况一团糟。

为什么？

更少的目光在审视专有方案的安全性。更少的人设计所采用的安全算法。更少的人实现它们。更少的人做代码审查。更少的白帽安全专家去尝试寻找其中的漏洞。

专有方案来自专有厂商，其中大多数都有自己的商业计划和路线图。对他们来说，投资安全的优先级往往排第二，尤其是在融资、吸引用户、让客户付费之后。

不使用 WebRTC 的专有方案，必须想办法在浏览器环境中运行。这意味着要使用一些取巧的手法，而这些手法又会带来安全漏洞。问问 Zoom 就知道，他们那些与”不使用 WebRTC”相关的漏洞是怎么回事。

二十多年前，我在大学修了一学期的软件安全课程，讲师给的最佳建议是：永远不要自己设计或实现安全算法。无论是底层的算法，还是更高层的安全抽象。为什么？因为只要留下一个小 bug（编码 bug 或逻辑 bug）就很容易毁掉一套出色的安全机制。专有安全 = 一场迟早要发生的灾难。

即便是大牌公司也会搞错。2020 年，FTC 指控 Zoom 将其会议宣传为端到端加密，而加密密钥实际掌握在 Zoom 自己手里。Zoom 达成和解，最终裁定于 2021 年 2 月生效。如果你说”端到端加密”，那最好是真的（我清单中的第 7 条规则）。

如果你看看更老的标准化 VoIP 方案，如 SIP 和 H.323 它们提供加密与安全能力，但这些都是可选项。在多数网络上，它们甚至根本没被启用，因为这会降低方案容量或增加 CPU 负载。过去在 discuss-webrtc 上有大量关于”明文传输 WebRTC 媒体”的问题，不知怎的，开发者们觉得那是个好主意。

我们需要把现代网络视为零信任网络。让每个组件各自处理自己的安全，而不是依赖外部力量来提供安全。WebRTC 采取的正是这种做法。

通话中的 AI：房间里多了另一位”用户”​

智能体化 AI 已经到来。它触及我们做的每件事，WebRTC 也是其中之一。

WebRTC 本身如今正被 AI 加固，也很可能正被 AI 攻击。我在这里想谈的是，与 AI 相关的功能如何影响 WebRTC 中的安全与隐私。下面逐项看看这些功能，理解它们最终落在我们安全考量的什么位置：

• 背景虚化、背景替换与噪声隔离依赖机器学习算法。它们同时也是提升用户隐私的手段：把用户及其声音从其所在环境中”剥离”出来，确保环境不会泄露进会议。
• 字幕与转录需要语音转文本，而这主要在云服务器上运行，它们必须听到音频本身。当需要 E2EE 时，这些功能会被禁用；而在存在时，它们需要额外的安全保护。
• 摘要、会议记录、虚拟助手都会以”会议参与者”的身份加入，用一个模型读取转录内容，这同样为你（以及用户）带来了需要处理的隐私/安全风险。
• 翻译几乎总是基于云端的。随着实时翻译成为常态，这也会影响你所作的隐私承诺。
• 云录制与分析假设你对媒体进行了解密，而路径中很可能有一个 AI 在查看其中内容。
• 语音智能体……嗯……把它们当作实时参与者就好，只不过它们坐在云端，而且很有可能把那些数据用于训练模型，甚至更糟。

其中一些能力可能可以改用设备端而非云端服务来实现，从而更私密、更安全。这就需要你去核查具体设备，以及你的应用支持这些路径的可能性。

如果你把服务宣传为端到端加密，那么这些功能每一项都是你必须回答的问题：它是否开启、它在哪里运行、谁能看到媒体？基于云的 AI 功能与端到端加密承诺，无法在同一场会议中同时成立。我那份 WebRTC 安全清单的第 7 条规则讲的正是这件事。

你在 WebRTC 安全中的角色

WebRTC 是安全的，但你的应用不是。

换个说法：

你的应用有多安全，取决于你做到多安全。

确保它安全：

从清单开始。​ 下载我的 WebRTC 安全清单。它涵盖 7 条规则，指出 WebRTC 需要你协助才能保持安全的环节：用户身份、日志保留了什么、TURN 凭证、访客链接、房间链接、摄像头的释放，以及端到端加密的宣称。每条规则都配有一段提示词，你可以在代码仓库根目录用 AI 编程智能体运行，从而弄清你的应用处于什么状态。

然后补齐缺口。​ 清单中的每条规则，都是我《WebRTC 安全与隐私精要》课程中的一课，我在其中深入讲解如何修复清单发现的问题，以及清单未覆盖的领域。

依靠 WebRTC 自带的安全能力，并在你的应用上下文与需求之上叠加补充（其中很大一部分会落在认证、授权与身份要素上）。

不要在 WebRTC 安全上犯新手错误。​ 它们日后会回过头来咬你。

关于 WebRTC 安全的常见问题

WebRTC 安全吗？ 是的。WebRTC 大概是目前最安全的 VoIP 协议。这源于它从设计之初就考虑了安全，因为它必须在一个本身永远无法被视为安全的浏览器环境中运行。这不意味着它毫无缺陷——只是说当安全问题被发现时，通常会被迅速处理，并因现代浏览器的自动更新机制而更快地传递给用户。

WebRTC 的 IP 泄露是怎么回事？ WebRTC 需要 IP 地址来连接用户，因此会收集这些地址并在协商过程中共享。由于暴露本地 IP 地址被认定为一个隐私问题，WebRTC 引入了对本地 IP 地址的 mDNS 支持，使本地网络中的用户仍能被发现，而无需在协商中暴露本地 IP 地址。你的公网 IP 地址仍会在点对点通话中共享给对方。若要隐藏它，可通过 TURN 服务器中继媒体。

我能在 WebRTC 中发送未加密的媒体吗？ 不能。按设计，WebRTC 会加密用户之间发送的所有媒体。在 WebRTC 中无法（除非改动实现本身）以明文发送媒体。

使用 WebRTC 是否意味着我的服务是安全的？ 不是。虽然 WebRTC 在设计上是安全的，但它只是你所使用服务中的一个组件。因此，它提供的安全性取决于你所使用服务的安全性。要检查你的应用哪里需要改进，请使用我的 WebRTC 安全清单。

WebRTC 提供端到端加密吗？ WebRTC 在终止加密的实体之间提供端到端加密。如果你的服务是点对点运行的（无论是否有 TURN 中继），那么它就是端到端加密的——前提是你信任自己的信令服务器，因为加密指纹正是在那里交换的。MCU 必须访问媒体才能混流，因此会破坏端到端加密。朴素的 SFU 同样能访问未加密的媒体，但使用 SFrame 时，参与者自行加密媒体，并把密钥与服务器隔离。请记住，录制、直播、转录和会议摘要等功能需要访问媒体，因此与端到端加密并不相容。

WebRTC 的安全性比 Zoom 更好吗？ 是的，但这不是一个对等的比较。WebRTC 是一份规范，它提供了很高水平的安全性。而在它之上构建的应用仍然可能使其变得不安全。Zoom 是专有方案，外部审视其安全性的人更少。2020 年，FTC 指控 Zoom 将会议宣传为端到端加密，而加密密钥实际掌握在 Zoom 手中，和解于 2021 年 2 月最终生效。

使用 AI 功能会破坏端到端加密吗？ 通常是的。在通话中使用 AI，意味着房间里多了一位用户，而这位用户很可能在云端。转录、会议摘要、翻译和云录制都需要访问解密后的媒体，这也是微软、Zoom 等厂商在开启端到端加密时会禁用这些功能的原因。多数情况下，端到端加密只有在 AI 运行于用户自有设备上时才得以保持。