在开始之前
一切都开始于Google Project Zero,结果可以在Github 目录中，里面包含测试RTP流的工具（和一些记录的bug）。
一些值得注意的：
- 这些bug很重要，尝试修复它们。
- 这不是世界末日。一些bug已经被发现。很多bug存在已久，每天都在发生，有一些bug很麻烦。
- 这些不是WebRTC的最后一个，也不是最严重的bug。你可以借鉴NewVoiceMedia，查看它们最近的音频问题。
什么是模糊测试：
维基百科对此的解释：
模糊测试是一个自动化的软件测试技术，包括提供无效，不被期待的，或随机数据作为计算机程序的输入。接着监测程序，找到例外，例如崩溃，失败的内置代码断言，或潜在的内存泄露。
对我来说，模糊测试是为了得到异常输入的结果，这些结果是开发者不期待的，或没有测试过的。这将会导致未定义的行为，说得好听一点就是bug。在某些情况，bug无所谓，某些情况，使人讨厌，带来麻烦：
- 它可能导致软件崩溃
- 读写它不应该去的地方（溢出）
- 死锁
- 内存泄露
Bug的类型是各种各样的。
一个好的异常输入理论上可以被用来授予你管理员权限，或允许你读取你不应该接触到的内存区域。
一个简单的解释是：假设你的软件期待用户邮件长度为40个字符长。比它短没问题，但是如果长度超过40字符呢？某些地方，会存在一段代码，检查长度并且表明长度过长。如果没有的话，我们就接触到了未被定义和潜在的安全漏洞。
同样的事情可以发生在网络协议中。机器需要解析数据的结构。所以如果你改变数据，接近期待的结构，但是偏离了一点，你将会接触到未定义的漏洞。
模糊测试就是用来发现这些问题的，在正确的地方添加随机性，来发现未定义的软件行为。
让我给你讲个睡前故事
我模糊的生活起始于芬兰，尽管我从未到过那里。
在奥卢大学，某一天，一个叫做PROTOS Test Suite的词被创建出来。在那时，我是领导开发维护RADVISION的H.323协议栈的项目经理。许多供应商都使用我们的源代码建立VoIP产品。
PROTOS Test-Suite就是安全测试。试图发现导致崩溃的崩溃。它们选择最好的接入点。它们被这样形容：
测试单元的目的是评估H.225.0的实施级安全性和稳定性。它是一个负责发信和建立H.323通信的协议。
我加粗了重要部分。奥卢的人决定跟随H.323的拾取线，并尝试找出令人讨厌的将会混淆H.323设备的设置信息。
它们确实混淆了。PROTOS有4497设置信息。我第一次运行的时候，50%导致H.323栈崩溃。我花了一周时间编写软件来自动修复它产生的所有麻烦事。我钦佩它们的工作，和让我做的工作。
这产生了它自己的CERT漏洞记录，我们花了很长时间帮助顾客更新栈，并使它可以正常进行安全修复。
我相信我们的一些顾客实际上就是因为这点才更新升级系统的。我也确定有些人不是因为这点。我还假设一些客户的客户没有升级他们自己的部署设备。
所有这些发生在2004年。在WebRTC之前，在云出现之前，在移动端出现之前。使用了我们今天在WebRTC中也用到的RTP/RTCP协议，还有VoIP中相同的技术和机制。
人们那时为什么不关注RTP的易受攻击点呢？我们会讨论的。
Google的Project Zero和视频会议
今年，Google的Project Zero决定转向视频会议。方向是WebRTC. Natalie Silvanovich负责此事并连续写了5篇文章：首先是关于她的选择和WebRTC本身带来的挑战。在文章中，她写到：
我从WebRTC的发信阶段出发，因为它是一个不需要用户交互的攻击层，WebRTC使用SDP发信。
我查阅了WebRTC SDP解析器代码，但是没有找到任何漏洞。我还对其进行编译，使得它能在命令行接收SDP文件，并进行模糊化，但是我仍然没找到任何漏洞。
我决定查看WebRTC如何对RTP进行处理。尽管RTP不是一个少交互的攻击层，因为用户经常在RTP流量处理之前接收通话，但是接收通话显然对用户来说是一个合理的动作。建立端对端模糊化显然更费时间。
在此需要提醒几点：
- WebRTC对发信层（SDP解析器）能够有效的抵抗这些攻击。
- 发信和SDP，对于奥卢的人员使用他们的测试单元来说是等价的。
- 有一个词汇叫应答。这不是WebRTC做的。它连接了各个session。有时直接连接，有时间接连接。在所有情形下，在RTP上面都存在用户需要首先通过的层。
- 创建这样一个测试，在RTP层进行端对端模糊化测试是费时间的。
RTP不是第一个攻击层，也不是第一交互层的事实使如何探索它不太明显。
这两点结合起来，费时，探索方式不清晰，使人们直到今天也不愿意花时间在上面。
WebRTC行业的模糊感受
一个例子是Philipp Hancke着眼于Janus媒体服务器并模糊化REMB RTCP信息。
他的攻击因为以下几点而非常成功：
- 他具有Janus的源代码，能够对想要攻击的区域进行隔离。这样攻击起来就比Project Zero的做法更容易。
- 他选择了一个目标，它会多次崩溃，它是一条信息，埋藏在协议内部，目标是会话连接之后会多次发生的控制逻辑。
你应该让模糊测试远离你的WebRTC App么？
或许不应该。
让我们看：在你想要做但今天不做的测试列表中，模糊测试恰好适合那些你从未找到时间和优先级去处理的事情。
好事？对我们中的大多数，模糊测试是其它人应该正在做着的事情。
如果你在使用CPaaS供应商，他的任务是保护发信和媒体服务器免受这样的攻击。
如果你在浏览器上运行，那些维护浏览器的WebRTC代码的人需要对此负责。
你应该考虑你自己App逻辑下的模糊测试，还有在你控制下的，但是WebRTC呢？还有RTP呢？那些不是你应该做的。
你的任务是询问供应商，它们是否进行了安全测试，它们已经做了什么。
谁应该关心模糊测试？
以下是应该处理模糊测试的人们：
- 如果你开发，部署自己的媒体服务器和客户端框架，你应该关心。
- 如果你正在使用第三方，你需要确保你经常更新。
- CPaaS供应商。
- 浏览器供应商。
