WebWormhole安全审计：验证点对点传输的完整性与机密性

1. 项目概述：为什么我们需要审计WebWormhole？

最近在和朋友讨论一些敏感文件的传输方案时，又聊到了WebWormhole这个工具。它最大的魅力在于“无服务器”和“点对点”，文件或文本直接从你的浏览器飞到对方的浏览器，中间不经过任何第三方服务器存储。听起来很酷，对吧？但作为一个搞安全出身的，我的第一反应永远是：它真的安全吗？我怎么知道传输过程中数据没被篡改？我怎么确认只有我和接收方能看到内容？这就是“完整性”和“机密性”两个核心安全属性的问题。

很多人用这类工具，觉得链接一生成、一分享就完事了，默认工具会处理好一切。但事实上，任何安全机制都不是魔法，背后都是一系列具体的技术协议和实现细节。WebWormhole虽然利用了现代浏览器内置的WebRTC能力，但其安全性的根基并非坚不可摧，它依赖于对WebRTC安全协议栈的正确使用和配置。一次简单的“发送-接收”操作，背后可能涉及DTLS握手、SRTP媒体加密、SDP交换等多个环节，任何一个环节的实现瑕疵或配置不当，都可能成为安全短板。

因此，对WebWormhole进行安全审计，绝不是吹毛求疵，而是每个对数据安全有要求的用户或开发者应该掌握的技能。这份指南的目的，就是带你像安全研究员一样，层层剥开WebWormhole的传输过程，亲手验证其点对点传输的完整性和机密性是否名副其实。我们会从原理入手，到实操验证，最后分享排查技巧，让你不仅能安全地使用它，更能理解它为何安全。

2. 核心安全机制原理解析

要审计，首先得知道审计的对象是什么。WebWormhole的安全并非自创一套密码学，而是巧妙地“站在巨人的肩膀上”，重度依赖WebRTC（Web实时通信）标准中已经过严格考验的安全协议。理解这套机制，是后续所有验证工作的基础。

2.1 信任模型的根本转变：从服务器到端到端

传统文件传输（如邮件附件、网盘）的信任模型是中心化的。你上传文件到服务器，信任服务器会妥善保管并正确分发给接收方。这个模型下，服务器的管理员、潜在的入侵者、甚至服务提供商本身，都可能成为数据泄露或篡改的风险点。

WebWormhole实现了一种根本性的转变：去信任化（或最小化信任）的端到端模型。它的信号服务器（Signaling Server）只做一件事——帮助两个互不知晓网络地址的浏览器“搭上线”。这个过程类似于电话总机，它只负责接通双方，但一旦通话建立，总机就听不到通话内容了。在WebWormhole中，信号服务器交换的是用于建立直接P2P连接的“联系信息”（SDP描述符），而真正的数据传输通道（PeerConnection）一旦建立，后续的所有数据流完全在浏览器之间直接加密传输，不再经过信号服务器。这是我们验证机密性的前提：只要P2P通道的加密是牢靠的，那么信号服务器即使被攻破，也无法解密过往或正在传输的数据内容。

2.2 加密与完整性保护的三重奏：DTLS, SRTP/SCTP

当两个浏览器通过信号服务器交换了SDP信息后，它们会尝试建立直接的P2P连接。这个连接的安全由以下协议保障，它们共同构成了机密性和完整性的基石：

1. DTLS（数据报传输层安全）握手：这是整个安全通道的“奠基仪式”。DTLS可以理解为为UDP协议设计的TLS，它负责在不可靠的UDP数据报上建立一个安全的、经过身份验证的通道。握手过程大致如下：

   • 密钥交换：双方使用椭圆曲线密码学（通常是ECDHE）协商出一个只有双方知道的“主密钥”。这个过程确保了即使握手过程被监听，攻击者也无法计算出这个主密钥（前向安全性）。
   • 身份验证：在WebRTC的默认配置下，通常使用“自签名证书”进行身份验证。这意味着浏览器会为每次会话临时生成一个证书，用于在DTLS握手过程中证明“我是刚才发起连接的那个实体”。虽然这个证书没有公认的CA签名，但在点对点场景下，只要双方在信号交换阶段确认了对方的“指纹”（证书哈希值），就能防止中间人攻击。WebWormhole通过wormhole码（一串单词）的交换，间接保证了双方获取的SDP（内含证书指纹）是可信的。
   • 派生密钥：握手成功后，双方从主密钥派生出用于后续实际数据加密的密钥块。

2. SRTP（安全实时传输协议）与SCTP over DTLS：DTLS握手建立的安全通道像一条加密隧道。具体跑什么数据，用什么格式加密，则由上层协议决定。

   • 对于音视频流（如果传输），使用SRTP。它使用从DTLS派生的密钥对每一个RTP数据包进行加密和完整性保护（使用HMAC-SHA1）。
   • 对于任意数据（WebWormhole传输文件的主要方式），使用SCTP（流控制传输协议）运行在DTLS之上（即SCTP over DTLS）。SCTP本身提供了可靠、有序的消息传输。而DTLS层则为所有的SCTP数据块提供了机密性（加密）和完整性（防篡改）保护。这是验证的关键：文件数据被切割成消息，通过SCTP发送，而整个SCTP报文又被封装在DTLS记录中，受到DTLS级别的加密和MAC（消息认证码）保护。

注意：这里有个常见的误解。有人以为文件传输是“明文分块后发送”。实际上，在正确的WebRTC DataChannel配置下（ordered: true, maxRetransmits: 0等），数据是通过SCTP/DTLS管道传输的，从离开发送方浏览器到进入接收方浏览器内存，始终处于DTLS加密隧道内。网络嗅探器抓到的只能是加密的DTLS记录。

2.3 “信号完整性”与传输完整性的区别

最近“信号完整性”这个词在硬件和高速电路设计领域很热，但在这里我们需要做一个严格的区分。在WebWormhole的语境下，我们关注的是数据传输的完整性和机密性，而非电信号的质量。

• 信号完整性（硬件概念）：指的是电子信号在传输路径上（如电路板走线）的波形质量，确保接收端能正确解读发送端的逻辑状态。这与我们无关。
• 传输完整性（安全概念）：指的是数据内容从发送端到接收端的过程中，没有被未授权地篡改、插入或删除。这是通过密码学哈希函数（如DTLS和SRTP中使用的MAC算法）来保证的。接收方会用共享的密钥验证每个数据包的MAC，如果不匹配，则说明数据在传输中被篡改，连接会被终止。

我们的审计，完全聚焦于后者——密码学保证的传输完整性。

3. 实操审计：验证机密性与完整性的四步法

理论讲完了，现在进入实战环节。我们如何像黑客一样，去验证这些安全机制是否真的在起作用？以下是一套从外部观察到内部检查的递进方法。

3.1 第一步：网络流量捕获与初步分析

这是最直观的方法：直接看看网络上跑的是什么数据。

工具准备：

• Wireshark：网络封包分析的金标准。
• 浏览器：Chrome或Firefox。
• 一个简单的WebRTC测试页面或直接使用WebWormhole网站。

操作与验证：

1. 打开Wireshark，开始捕获你电脑的网络流量（如Wi-Fi或以太网接口）。
2. 在浏览器中打开WebWormhole，发送一个文本消息或小文件。
3. 在Wireshark中停止捕获，并应用过滤器。这是关键的一步。
   • 过滤器1：dtls：直接过滤出所有DTLS协议的数据包。你应该能看到一系列“Client Hello”、“Server Hello”、“Certificate”、“Application Data”等类型的DTLS记录。如果你能看到明文的“Application Data”内容，那说明DTLS加密失效了——这几乎不可能在标准浏览器中发生。正常情况下，你看到的“Application Data”记录，其负载（Payload）部分是完全加密的、不可读的二进制数据。这初步证实了机密性：网络上的窃听者看不到实际内容。
   • 过滤器2：stun || turn：查看用于NAT穿越的STUN/TURN协议流量。这些流量是明文的，但内容仅限于网络地址发现和中继协商，不包含你的文件数据。如果传输因为对称NAT等原因失败了，可能会 fallback 到 TURN 中继，这时数据会经过TURN服务器。重要提示：即使走TURN，应用层数据（你的文件）仍然在DTLS加密隧道内，TURN服务器只是转发加密后的DTLS包，它无法解密。你可以通过检查TURN信道上的数据包负载是否为加密乱码来验证。

实操心得： 在Wireshark中，DTLS握手阶段的“Certificate”包可能会显示浏览器生成的临时证书信息，这是正常的。真正的机密性验证在于握手完成后的“Application Data”包，其负载必须呈现为随机乱码。如果发现任何可读的字符串（如文件片段、文本），应立即停止使用并报告漏洞。

3.2 第二步：浏览器开发者工具深度探查

对于无法直接抓包（如使用HTTPS网站，Wireshark需配置解密）或想更深入了解内部状态的用户，浏览器自带的开发者工具是宝库。

在Chrome/Edge中操作：

1. 打开开发者工具（F12），进入“Network”（网络）标签页。
2. 开始一次WebWormhole传输。
3. 在网络请求列表中，寻找类型为“WebSocket”（ws或wss）的连接。这极大概率就是连接到WebWormhole信号服务器的通道。点击该请求，查看“Messages”标签页。你应该能看到JSON格式的SDP offer/answer交换。这里面的candidate（网络候选地址）和fingerprint（证书指纹）是明文，但没关系，它们只是用来建立连接的信令。
4. 关键步骤：转到“Console”（控制台）标签页。在传输过程中，尝试输入以下命令来检查PeerConnection的状态（这需要页面没有对RTCPeerConnection对象进行严格封装，对于测试页面更有效）：

   // 这通常需要你在代码层面能访问到peerConnection实例 // 对于透明化的测试，可以查看浏览器的webrtc内部状态页面 // Chrome/Edge地址栏输入：chrome://webrtc-internals

5. 访问chrome://webrtc-internals这个特殊页面。这里展示了浏览器内所有WebRTC连接的状态。找到对应的PeerConnection，查看其统计信息。
   • 关注dtlsState：应该为"connected"，表示DTLS安全通道已成功建立。
   • 查看dataChannels列表：确认你的DataChannel已打开。
   • 在stats中，寻找transportId相关的统计项，里面会有selectedCandidatePair，显示当前使用的本地和远程IP/端口，以及dtlsCipher：这里会显示协商使用的加密套件，例如"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"。一个强加密套件的出现，是机密性的有力证明。

在Firefox中操作：

1. 打开开发者工具（F12），进入“网络”标签页，同样查看WebSocket信令。
2. 在地址栏输入about:webrtc打开WebRTC内部状态页面。这里的信息比Chrome的更直观一些，直接列出了活动的PeerConnection，并可以查看其本地和远程描述（SDP）。
3. 在SDP描述中，寻找a=fingerprint:行和a=crypto:行（较老版本）。fingerprint就是用于DTLS握手证书验证的哈希值。确保双方交换的SDP中的指纹与about:webrtc中显示的实际连接使用的证书指纹一致，可以防止信令被篡改导致的中间人攻击。

3.3 第三步：完整性验证的主动测试

机密性确保了数据不被看，完整性则要确保数据不被改。如何测试完整性保护是否生效？我们可以尝试进行“中间人篡改测试”。由于WebWormhole是P2P的，直接在网络层做中间人比较困难，但我们可以通过一个更简单的思路来验证：破坏数据的完整性，看连接是否存活。

模拟测试方法：

1. 使用代理工具篡改：配置一个本地代理（如Burp Suite或mitmproxy），并让浏览器通过该代理上网。然后尝试进行WebWormhole传输。

   • 预期结果：由于DTLS握手要求端到端认证，代理无法提供正确的证书（除非你向浏览器信任了代理的CA证书，但这在WebRTC的DTLS中情况复杂），DTLS握手会失败，P2P连接根本无法建立。这本身就证明了完整性（和身份验证）机制在起作用——它阻止了未经验证的中间人介入。
   • 进阶测试：如果你技术足够强，可以尝试在代理上对已建立的DTLS流进行“位翻转”攻击（即随机修改加密数据包中的某些位）。在理论上，由于DTLS记录带有MAC，接收方解密并验证MAC时会失败，导致连接立即被终止。观察WebWormhole是否迅速报错（如“连接断开”、“数据损坏”），而不是继续传输损坏的文件。

2. 文件哈希对比：这是最直接、用户可操作的方法。在发送端，计算待传输文件的哈希值（如SHA-256）。通过WebWormhole传输文件。在接收端，对收到的完整文件再次计算SHA-256哈希值。

   • 操作：发送方在终端执行sha256sum 我的文件.zip，将得到的哈希值通过另一个可信通道（比如当面口头核对、通过已加密的Signal/WhatsApp消息）告知接收方。
   • 验证：接收方收到文件后，同样执行sha256sum 收到的文件.zip，对比两个哈希值。
   • 结果解读：如果哈希值完全一致，则强有力地证明了文件在传输过程中完整性未被破坏。因为即使是一个比特的改动，SHA-256也会产生完全不同的哈希值。这综合验证了从发送方内存到接收方硬盘的整个端到端过程的完整性。

3.4 第四步：代码层面的安全配置审查（针对开发者）

如果你是开发者，或者打算基于WebRTC/WebWormhole的类似原理构建应用，那么审查代码中的安全配置至关重要。

关键配置点检查：

1. RTCPeerConnection配置：

   const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }], // 关键：确保没有使用不安全的遗留协议 // sdpSemantics: 'unified-plan' // 现代、更安全的SDP格式 });

   确保没有主动禁用或降级安全选项。浏览器默认是安全的，但显式配置可以避免依赖默认值的变化。

2. RTCDataChannel配置：

   const dc = pc.createDataChannel('fileTransfer', { ordered: true, // 保证顺序，有助于完整性校验 maxPacketLifeTime: null, // 根据需求调整 // 注意：WebRTC DataChannel默认是可靠且受DTLS保护的，无需额外配置加密 });

   最重要的是理解：DataChannel的可靠性（ordered,maxRetransmits）是传输层属性，而安全性（加密、完整性）由底层的DTLS协议保障，开发者通常无需也无法直接配置。

3. 信令通道安全：虽然信令本身不传输密文数据，但信令被篡改会导致连接被劫持。确保你的信令服务器使用WSS（WebSocket Secure），并且前端页面通过HTTPS加载。这是防止信令被中间人篡改的基本要求。WebWormhole官网默认就使用了HTTPS。

常见问题：

• Q：我看到了a=crypto:行，这是否意味着加密较弱？
  • A：a=crypto:是旧的、已废弃的SDP属性，用于SRTP的密钥协商。现代WebRTC都使用DTLS-SRTP，即在DTLS握手后派生SRTP密钥。在SDP中你会看到a=fingerprint:和a=setup:（指示DTLS角色）。如果只有a=crypto:而没有DTLS相关行，那可能意味着使用了不安全的、已废弃的加密方式，这是一个危险信号。幸运的是，主流浏览器早已强制使用DTLS-SRTP。

4. 高级威胁模型与局限性分析

没有任何系统是绝对安全的。在验证了WebWormhole在标准使用场景下的安全性后，我们还需要了解它的安全边界和潜在风险，这才是深度审计的体现。

4.1 潜在的攻击面与缓解措施

4.2 WebWormhole的固有局限性

理解一个工具不能做什么，和它能做什么一样重要。

1. 匿名性不足：WebRTC建立P2P连接时，为了穿越NAT，会通过STUN服务器发现并交换真实的IP地址。这意味着通信双方会互相知道对方的公网IP。信号服务器也能看到双方的IP。WebWormhole不提供匿名性保护。
2. 前向保密依赖于会话：DTLS握手使用的ECDHE提供了会话前向保密。这意味着每次新的WebWormhole连接（新的wormhole码）都会生成新的临时密钥。一旦会话结束，密钥被丢弃，即使长期私钥泄露，过去的会话也无法被解密。但是，如果攻击者在会话进行时已经监听了所有流量并记录了密文，并且之后攻破了其中一方的设备获取了内存中的会话密钥，那么该次会话仍可能被解密。不过，这要求攻击是实时的，难度很高。
3. 依赖浏览器安全：整个安全模型建立在浏览器的WebRTC实现是正确且安全的基础上。如果浏览器存在严重漏洞，所有上层安全都形同虚设。
4. 无法验证接收方身份：WebWormhole通过一个共享的、短暂的“wormhole码”来配对双方。它验证了“持有相同码的人”是对方，但无法验证这个人的真实身份是谁。这适用于临时性文件共享，但不适用于需要强身份认证的场景。

5. 构建你自己的自动化审计脚本

对于需要频繁审计或集成到CI/CD流程中的开发者，手动抓包和查看浏览器并不高效。我们可以利用一些命令行工具和浏览器自动化框架来构建简单的自动化审计脚本。

思路：使用Puppeteer（控制Chrome）或Playwright（跨浏览器）自动化一次WebWormhole传输，同时从浏览器内部获取关键安全参数进行断言。

以下是一个概念性的Puppeteer脚本框架，用于验证DTLS加密套件是否强效：

const puppeteer = require('puppeteer'); const https = require('https'); (async () => { const browser = await puppeteer.launch({ headless: false }); // 非无头模式以便观察 const page = await browser.newPage(); // 监听DevTools Protocol事件，获取WebRTC日志（需要启用特定标志） const cdpSession = await page.target().createCDPSession(); await cdpSession.send('Network.enable'); await cdpSession.send('WebRTC.enable'); cdpSession.on('WebRTC.webrtcEvent', (event) => { console.log('WebRTC Event:', JSON.stringify(event, null, 2)); // 这里可以解析事件，查找peerConnection创建、ICE候选、DTLS状态等 }); // 访问WebWormhole await page.goto('https://webwormhole.io'); // 这里需要模拟用户操作：获取wormhole码，在另一个客户端连接等。 // 这部分的自动化非常复杂，因为涉及两个独立的浏览器实例交互。 // 更可行的简化审计是：只检查页面加载的WebRTC相关JS代码和安全头。 // 示例：检查是否使用WSS const requests = []; page.on('request', request => { if (request.url().includes('webwormhole.io') && request.resourceType() === 'websocket') { if (!request.url().startsWith('wss://')) { console.error('ERROR: Insecure WebSocket used for signaling!'); } } }); // 等待一段时间后关闭 await page.waitForTimeout(10000); await browser.close(); })();

更实际的自动化方向： 对于普通用户或开发者，更实用的“自动化”是编写一个简单的传输后验证脚本。例如，一个Python脚本，在发送文件后自动计算哈希并生成一个校验文件，接收方运行另一个脚本自动校验。

# sender_side.py (发送方) import hashlib import sys def generate_hash(file_path): sha256_hash = hashlib.sha256() with open(file_path,"rb") as f: for byte_block in iter(lambda: f.read(4096), b""): sha256_hash.update(byte_block) return sha256_hash.hexdigest() if __name__ == "__main__": file_to_send = sys.argv[1] file_hash = generate_hash(file_to_send) print(f"File: {file_to_send}") print(f"SHA-256: {file_hash}") # 可以将这个哈希值复制，通过其他安全通道发送给接收方

# receiver_side.py (接收方) import hashlib import sys def verify_hash(file_path, expected_hash): actual_hash = hashlib.sha256() with open(file_path,"rb") as f: for byte_block in iter(lambda: f.read(4096), b""): actual_hash.update(byte_block) return actual_hash.hexdigest() == expected_hash if __name__ == "__main__": received_file = sys.argv[1] expected_hash = sys.argv[2] # 从发送方获取的哈希值 if verify_hash(received_file, expected_hash): print("✅ Integrity verification PASSED. File is intact.") else: print("❌ Integrity verification FAILED! File may be corrupted or tampered.")

这个简单的哈希验证流程，虽然看起来“低级”，却是验证端到端完整性最可靠、最本质的方法，它不依赖于对传输协议复杂性的信任，而是基于密码学哈希函数的数学确定性。

经过从原理到实操、从外部观察到内部检查、从正面验证到威胁分析这样一轮下来，你应该对WebWormhole这类点对点传输工具的安全性有了立体的认识。它的安全不是玄学，而是建立在DTLS、SRTP等标准协议之上，通过浏览器严格实现的。审计的关键，在于理解这些协议如何被运用，并利用工具和方法去验证它们是否在正确工作。记住，真正的安全是一种持续验证的状态，而不是一个一劳永逸的开关。