反复改进
有了一个可以正常工作的示例（因为音频还不能用，所以最初只是视频形式）后，我们快速迭代了一些改进工作。例如密钥更改和解码帧头，后者看起来非常有趣。以前，在接收到加密的帧后，虚拟middlebox的解码器仅抛出错误，图片将被冻结。现在，我们利用VP8编解码器的某些属性，不对前几个字节进行加密，使解码器误以为该帧是有效的VP8。
点击此处试用实例。
Insertable Stream在帧上迭代（非数据包）
Insertable Stream API在编码器/解码器和打包器之间运行，后者将帧拆分为RTP数据包。虽然不能帮助我们通过WebAssembly插入自己的编码器（因为打包器无权访问原始数据），但打包器可以转换编码的帧。加密就是这种转换的一个例子。
这种做法早就有了，比如webrtc.org库已经有了能够用于帧加密的本机API。但是它从未公开给浏览器。令人惊讶的是，当前API并未使用它。详见channel_send.cc。此处的区别在于Insertable Streams并不同步。
与操作每个数据包相比，在帧级别进行操作还有另一个优势——不必担心加密会增加多少字节的开销。打包器负责分散数据包即可。
除此之外，该操作还可以轻松传递元数据，（对于视频帧而言）要考虑帧是关键帧还是增量帧。相应的API仍在不断变化，因此如果你要访问它，就要为将来的变化做好准备。毕竟这是一个实验性API，默认情况下仍未启用。
自查
在Chrome中，以上这些操作都很容易观察到。当使用–disable-webrtc-encryption标志在Chrome中禁用加密（仅在Chrome Beta和Canary中才能成功）时，你可以看到Wireshark运行地非常良好：
要查看数据包层级发生了什么的话，你需要Wireshark解码VP8（参见此处）。你需要更改“加密”以将0xff放入帧的所有元素中。您还需要在Chrome中禁用冗余（RED），以使Wireshark理解VP8数据包。（有关SDP处理的信息，请参见此处）。完成此操作后，结果将变为可见，并有助于说明API的运行级别。
我们看到的是VP8有效负载描述符不变，其后是0xff字节。这对于如何设计加密意义重大。有效负载描述符是路由数据包中的关键元素之一，因此SFU可以继续使用它。更重要的是，转换确实会更改帧本身，这在VP8 RFC中有所描述。
修复所有错误
样本的试用凸显了许多问题。例如，仅在端连接是发起方时，转换才应用于发送方级别。我们报告了错误，并很快进行了修复；Simulcast也不起作用。Simulcast即将在SFU大热，因为联播在这里显得非常重要。修复此程序要复杂一些。我很高兴看到最近登陆的联播网络平台测试（即使用“游乐场”方法）提供了一种简便的测试方法。
最后我提出了很多有关Chrome的问题（目前是八个问题，还增加了九个改进示例的请求）。这些问题很快得到了解决。表明Chrome WebRTC团队将其视为一项高度优先的项目，以试图将API推入Chrome 83。WebRTC开发应以这种方式进行：错误能迅速得到修复，并且对提交文件的响应“能带来更多”。非常感谢Harald Alvestrand，Marina Ciocea和Guido Urdaneta！
WebWorker支持
Insertable Streams API看似不起眼的一个作用：流是可传输的，也就是可以将转换移动到WebWorker。
从主线程卸载加密可以提高性能，所以我开始在此方面探索。我想出来的模型是将每个帧传递给worker，在那里进行加密，然后再传递回去。事实证明这样行不通。这个操作仅传输流，将所有处理工作转移给了工作人员。
在示例中，或是我个人游乐场版本中实施该操作后，代码的组织方式令人瞠目结舌。
样本的PR很好地显示了这一点。
现在，所有的加密/解密和密钥管理都在一个单独的文件中进行，该文件易于在Chrome DevTools中进行检查。这意味着代码是完全隔离的，所有通信都是通过worker.postMessage进行的。文件相对较小，因此易于审核。这对于涉及密码学的任何代码段都非常有用。
一次成功的实验
该API能够为基于Chrome的WebRTC应用程序实施端到端加密。因为使用TransformStream的一般设计是可靠的。有趣的是，我们可以通过允许访问未编码帧的附加功能启用哪些WebRTC NV用例。
我欣赏API与WebWorker协同工作的方式，特别是它如何允许隔离和验证我们编写的任何加密代码的方式。
从实验迁移到实际应用需要更多的努力。对于实施加密和密钥管理尤其如此。
文章地址：https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/
原文作者：Philipp Hancke
