1. 项目概述为什么我们需要审计WebWormhole最近在和朋友讨论一些敏感文件的传输方案时又聊到了WebWormhole这个工具。它最大的魅力在于“无服务器”和“点对点”文件或文本直接从你的浏览器飞到对方的浏览器中间不经过任何第三方服务器存储。听起来很酷对吧但作为一个搞安全出身的我的第一反应永远是它真的安全吗我怎么知道传输过程中数据没被篡改我怎么确认只有我和接收方能看到内容这就是“完整性”和“机密性”两个核心安全属性的问题。很多人用这类工具觉得链接一生成、一分享就完事了默认工具会处理好一切。但事实上任何安全机制都不是魔法背后都是一系列具体的技术协议和实现细节。WebWormhole虽然利用了现代浏览器内置的WebRTC能力但其安全性的根基并非坚不可摧它依赖于对WebRTC安全协议栈的正确使用和配置。一次简单的“发送-接收”操作背后可能涉及DTLS握手、SRTP媒体加密、SDP交换等多个环节任何一个环节的实现瑕疵或配置不当都可能成为安全短板。因此对WebWormhole进行安全审计绝不是吹毛求疵而是每个对数据安全有要求的用户或开发者应该掌握的技能。这份指南的目的就是带你像安全研究员一样层层剥开WebWormhole的传输过程亲手验证其点对点传输的完整性和机密性是否名副其实。我们会从原理入手到实操验证最后分享排查技巧让你不仅能安全地使用它更能理解它为何安全。2. 核心安全机制原理解析要审计首先得知道审计的对象是什么。WebWormhole的安全并非自创一套密码学而是巧妙地“站在巨人的肩膀上”重度依赖WebRTCWeb实时通信标准中已经过严格考验的安全协议。理解这套机制是后续所有验证工作的基础。2.1 信任模型的根本转变从服务器到端到端传统文件传输如邮件附件、网盘的信任模型是中心化的。你上传文件到服务器信任服务器会妥善保管并正确分发给接收方。这个模型下服务器的管理员、潜在的入侵者、甚至服务提供商本身都可能成为数据泄露或篡改的风险点。WebWormhole实现了一种根本性的转变去信任化或最小化信任的端到端模型。它的信号服务器Signaling Server只做一件事——帮助两个互不知晓网络地址的浏览器“搭上线”。这个过程类似于电话总机它只负责接通双方但一旦通话建立总机就听不到通话内容了。在WebWormhole中信号服务器交换的是用于建立直接P2P连接的“联系信息”SDP描述符而真正的数据传输通道PeerConnection一旦建立后续的所有数据流完全在浏览器之间直接加密传输不再经过信号服务器。这是我们验证机密性的前提只要P2P通道的加密是牢靠的那么信号服务器即使被攻破也无法解密过往或正在传输的数据内容。2.2 加密与完整性保护的三重奏DTLS, SRTP/SCTP当两个浏览器通过信号服务器交换了SDP信息后它们会尝试建立直接的P2P连接。这个连接的安全由以下协议保障它们共同构成了机密性和完整性的基石DTLS数据报传输层安全握手这是整个安全通道的“奠基仪式”。DTLS可以理解为为UDP协议设计的TLS它负责在不可靠的UDP数据报上建立一个安全的、经过身份验证的通道。握手过程大致如下密钥交换双方使用椭圆曲线密码学通常是ECDHE协商出一个只有双方知道的“主密钥”。这个过程确保了即使握手过程被监听攻击者也无法计算出这个主密钥前向安全性。身份验证在WebRTC的默认配置下通常使用“自签名证书”进行身份验证。这意味着浏览器会为每次会话临时生成一个证书用于在DTLS握手过程中证明“我是刚才发起连接的那个实体”。虽然这个证书没有公认的CA签名但在点对点场景下只要双方在信号交换阶段确认了对方的“指纹”证书哈希值就能防止中间人攻击。WebWormhole通过wormhole码一串单词的交换间接保证了双方获取的SDP内含证书指纹是可信的。派生密钥握手成功后双方从主密钥派生出用于后续实际数据加密的密钥块。SRTP安全实时传输协议与SCTP over DTLSDTLS握手建立的安全通道像一条加密隧道。具体跑什么数据用什么格式加密则由上层协议决定。对于音视频流如果传输使用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网站。操作与验证打开Wireshark开始捕获你电脑的网络流量如Wi-Fi或以太网接口。在浏览器中打开WebWormhole发送一个文本消息或小文件。在Wireshark中停止捕获并应用过滤器。这是关键的一步。过滤器1dtls直接过滤出所有DTLS协议的数据包。你应该能看到一系列“Client Hello”、“Server Hello”、“Certificate”、“Application Data”等类型的DTLS记录。如果你能看到明文的“Application Data”内容那说明DTLS加密失效了——这几乎不可能在标准浏览器中发生。正常情况下你看到的“Application Data”记录其负载Payload部分是完全加密的、不可读的二进制数据。这初步证实了机密性网络上的窃听者看不到实际内容。过滤器2stun || turn查看用于NAT穿越的STUN/TURN协议流量。这些流量是明文的但内容仅限于网络地址发现和中继协商不包含你的文件数据。如果传输因为对称NAT等原因失败了可能会 fallback 到 TURN 中继这时数据会经过TURN服务器。重要提示即使走TURN应用层数据你的文件仍然在DTLS加密隧道内TURN服务器只是转发加密后的DTLS包它无法解密。你可以通过检查TURN信道上的数据包负载是否为加密乱码来验证。实操心得 在Wireshark中DTLS握手阶段的“Certificate”包可能会显示浏览器生成的临时证书信息这是正常的。真正的机密性验证在于握手完成后的“Application Data”包其负载必须呈现为随机乱码。如果发现任何可读的字符串如文件片段、文本应立即停止使用并报告漏洞。3.2 第二步浏览器开发者工具深度探查对于无法直接抓包如使用HTTPS网站Wireshark需配置解密或想更深入了解内部状态的用户浏览器自带的开发者工具是宝库。在Chrome/Edge中操作打开开发者工具F12进入“Network”网络标签页。开始一次WebWormhole传输。在网络请求列表中寻找类型为“WebSocket”ws或wss的连接。这极大概率就是连接到WebWormhole信号服务器的通道。点击该请求查看“Messages”标签页。你应该能看到JSON格式的SDP offer/answer交换。这里面的candidate网络候选地址和fingerprint证书指纹是明文但没关系它们只是用来建立连接的信令。关键步骤转到“Console”控制台标签页。在传输过程中尝试输入以下命令来检查PeerConnection的状态这需要页面没有对RTCPeerConnection对象进行严格封装对于测试页面更有效// 这通常需要你在代码层面能访问到peerConnection实例 // 对于透明化的测试可以查看浏览器的webrtc内部状态页面 // Chrome/Edge地址栏输入chrome://webrtc-internals访问chrome://webrtc-internals这个特殊页面。这里展示了浏览器内所有WebRTC连接的状态。找到对应的PeerConnection查看其统计信息。关注dtlsState应该为connected表示DTLS安全通道已成功建立。查看dataChannels列表确认你的DataChannel已打开。在stats中寻找transportId相关的统计项里面会有selectedCandidatePair显示当前使用的本地和远程IP/端口以及dtlsCipher这里会显示协商使用的加密套件例如TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256。一个强加密套件的出现是机密性的有力证明。在Firefox中操作打开开发者工具F12进入“网络”标签页同样查看WebSocket信令。在地址栏输入about:webrtc打开WebRTC内部状态页面。这里的信息比Chrome的更直观一些直接列出了活动的PeerConnection并可以查看其本地和远程描述SDP。在SDP描述中寻找afingerprint:行和acrypto:行较老版本。fingerprint就是用于DTLS握手证书验证的哈希值。确保双方交换的SDP中的指纹与about:webrtc中显示的实际连接使用的证书指纹一致可以防止信令被篡改导致的中间人攻击。3.3 第三步完整性验证的主动测试机密性确保了数据不被看完整性则要确保数据不被改。如何测试完整性保护是否生效我们可以尝试进行“中间人篡改测试”。由于WebWormhole是P2P的直接在网络层做中间人比较困难但我们可以通过一个更简单的思路来验证破坏数据的完整性看连接是否存活。模拟测试方法使用代理工具篡改配置一个本地代理如Burp Suite或mitmproxy并让浏览器通过该代理上网。然后尝试进行WebWormhole传输。预期结果由于DTLS握手要求端到端认证代理无法提供正确的证书除非你向浏览器信任了代理的CA证书但这在WebRTC的DTLS中情况复杂DTLS握手会失败P2P连接根本无法建立。这本身就证明了完整性和身份验证机制在起作用——它阻止了未经验证的中间人介入。进阶测试如果你技术足够强可以尝试在代理上对已建立的DTLS流进行“位翻转”攻击即随机修改加密数据包中的某些位。在理论上由于DTLS记录带有MAC接收方解密并验证MAC时会失败导致连接立即被终止。观察WebWormhole是否迅速报错如“连接断开”、“数据损坏”而不是继续传输损坏的文件。文件哈希对比这是最直接、用户可操作的方法。在发送端计算待传输文件的哈希值如SHA-256。通过WebWormhole传输文件。在接收端对收到的完整文件再次计算SHA-256哈希值。操作发送方在终端执行sha256sum 我的文件.zip将得到的哈希值通过另一个可信通道比如当面口头核对、通过已加密的Signal/WhatsApp消息告知接收方。验证接收方收到文件后同样执行sha256sum 收到的文件.zip对比两个哈希值。结果解读如果哈希值完全一致则强有力地证明了文件在传输过程中完整性未被破坏。因为即使是一个比特的改动SHA-256也会产生完全不同的哈希值。这综合验证了从发送方内存到接收方硬盘的整个端到端过程的完整性。3.4 第四步代码层面的安全配置审查针对开发者如果你是开发者或者打算基于WebRTC/WebWormhole的类似原理构建应用那么审查代码中的安全配置至关重要。关键配置点检查RTCPeerConnection配置const pc new RTCPeerConnection({ iceServers: [{ urls: stun:stun.l.google.com:19302 }], // 关键确保没有使用不安全的遗留协议 // sdpSemantics: unified-plan // 现代、更安全的SDP格式 });确保没有主动禁用或降级安全选项。浏览器默认是安全的但显式配置可以避免依赖默认值的变化。RTCDataChannel配置const dc pc.createDataChannel(fileTransfer, { ordered: true, // 保证顺序有助于完整性校验 maxPacketLifeTime: null, // 根据需求调整 // 注意WebRTC DataChannel默认是可靠且受DTLS保护的无需额外配置加密 });最重要的是理解DataChannel的可靠性ordered,maxRetransmits是传输层属性而安全性加密、完整性由底层的DTLS协议保障开发者通常无需也无法直接配置。信令通道安全虽然信令本身不传输密文数据但信令被篡改会导致连接被劫持。确保你的信令服务器使用WSSWebSocket Secure并且前端页面通过HTTPS加载。这是防止信令被中间人篡改的基本要求。WebWormhole官网默认就使用了HTTPS。常见问题Q我看到了acrypto:行这是否意味着加密较弱Aacrypto:是旧的、已废弃的SDP属性用于SRTP的密钥协商。现代WebRTC都使用DTLS-SRTP即在DTLS握手后派生SRTP密钥。在SDP中你会看到afingerprint:和asetup:指示DTLS角色。如果只有acrypto:而没有DTLS相关行那可能意味着使用了不安全的、已废弃的加密方式这是一个危险信号。幸运的是主流浏览器早已强制使用DTLS-SRTP。4. 高级威胁模型与局限性分析没有任何系统是绝对安全的。在验证了WebWormhole在标准使用场景下的安全性后我们还需要了解它的安全边界和潜在风险这才是深度审计的体现。4.1 潜在的攻击面与缓解措施攻击面描述对完整性/机密性的影响验证与缓解措施信令服务器篡改攻击者控制或入侵信号服务器篡改交换的SDP消息。可能导致中间人攻击MITM。如果攻击者将SDP中的证书指纹替换为自己的且双方未验证则后续建立的DTLS连接是与攻击者的机密性完全丧失。验证检查SDP中的afingerprint:值。WebWormhole通过“wormhole码”的共享在逻辑上保证了双方获取的SDP来自对方。缓解使用HTTPS/WSS连接信令服务器在UI上设计机制让用户二次确认连接指纹虽然对普通用户不友好。WebRTC实现漏洞浏览器自身的WebRTCDTLS, SRTP实现存在漏洞。可能绕过加密或完整性验证导致数据泄露或篡改。影响巨大但概率低。验证关注浏览器安全公告CVE。缓解保持浏览器最新版本使用经过广泛审计的浏览器Chrome, Firefox。旁路攻击通过计时攻击、功耗分析、电磁辐射等非直接方式推测密钥或数据。理论上可能破坏机密性。属于高成本攻击通常不针对普通用户。缓解现代密码学库和硬件已在设计上考虑缓解旁路攻击作为用户保持软件更新是关键。端点安全发送方或接收方的设备被恶意软件感染。完整性、机密性在端点上彻底失效。恶意软件可以直接读取浏览器内存中的明文数据。验证这是所有加密通信的终极弱点。缓解使用设备防病毒软件保持系统更新对极度敏感的数据考虑在应用层进行端到端加密如先加密文件再传输。流量分析攻击者虽然无法解密内容但可以观察传输的时间、数据包大小和频率。不影响内容机密性但可能泄露元数据如文件大小、传输活动。缓解WebRTC DataChannel本身不提供流量混淆。如需对抗此威胁需要更高级的工具如Tor、VPN但这超出了WebWormhole的设计范围。4.2 WebWormhole的固有局限性理解一个工具不能做什么和它能做什么一样重要。匿名性不足WebRTC建立P2P连接时为了穿越NAT会通过STUN服务器发现并交换真实的IP地址。这意味着通信双方会互相知道对方的公网IP。信号服务器也能看到双方的IP。WebWormhole不提供匿名性保护。前向保密依赖于会话DTLS握手使用的ECDHE提供了会话前向保密。这意味着每次新的WebWormhole连接新的wormhole码都会生成新的临时密钥。一旦会话结束密钥被丢弃即使长期私钥泄露过去的会话也无法被解密。但是如果攻击者在会话进行时已经监听了所有流量并记录了密文并且之后攻破了其中一方的设备获取了内存中的会话密钥那么该次会话仍可能被解密。不过这要求攻击是实时的难度很高。依赖浏览器安全整个安全模型建立在浏览器的WebRTC实现是正确且安全的基础上。如果浏览器存在严重漏洞所有上层安全都形同虚设。无法验证接收方身份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(fFile: {file_to_send}) print(fSHA-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等标准协议之上通过浏览器严格实现的。审计的关键在于理解这些协议如何被运用并利用工具和方法去验证它们是否在正确工作。记住真正的安全是一种持续验证的状态而不是一个一劳永逸的开关。
