端到端加密是一层额外保护，而不是忽略 TLS 警告或信任遭篡改代码的许可。
TLS 与端到端加密建立了两种不同的边界。这些边界在评估 VPN 和代理时同样重要。TLS 通常保护您的设备与服务之间的连接；正确实施且经过身份验证的端到端加密则将对话内容保护到接收方设备。能够读取 TLS 层并不必然意味着能够读取端到端加密的内容，但也不应因此认为 TLS 安全已不再重要。
如果中间方能够终止安全连接，那么除了查看传输数据，还可能修改响应或网页应用的代码。因此，“用 LVR1 绕过 TLS”并不是描述通信应用安全性的恰当说法。
根证书如何使检查成为可能？
在 HTTPS 连接中，设备会检查服务器的证书链和主机名。如果中间方提供的证书被应用判定为有效，它就可能建立两条独立连接：一条连接用户，另一条连接真实服务器。在这种情况下，中间方是其中一条 TLS 连接的终点，而不是仅靠观察数据包就破解了加密的窃听者。
仅仅安装任意证书并不够；应用必须信任它，连接检查也必须通过。Android 网络安全配置文档说明，信任策略可以因应用而异。以 Android 7.0 及更高版本为目标的应用默认不信任用户添加的证书，除非另有配置。
这是一种通用的技术机制。不能在没有证据的情况下据此判断某个运营商、国家或特定事件。连接中断或过滤本身并不能证明成功进行了 TLS 检查。
TLS 被解开后，能看到什么？
| 数据类型或情形 | TLS 检查的可能后果 |
|---|---|
| 仅受 HTTPS 保护的内容 | 受信任的中间方可能看到明文 |
| 已使用接收方有效密钥加密的消息 | 中间方通常看到的是密文，而非消息明文 |
| 路由、会话或辅助请求数据 | 暴露程度取决于服务的格式和设计 |
| 通过同一路径传来的网页版代码 | 修改代码可能威胁端点安全 |
| 服务不可用或流量被阻断 | 单靠加密无法建立连接 |
E2EE 对内容的保护还取决于接收方密钥的真实性，以及双方软件的完整性与安全状态。如果攻击者替换初始密钥，或能够在加密前看到消息的应用被篡改，仅仅具备 AES 或 ML-KEM 并不足够。
为什么网页版需要安全可靠的 TLS？
网页应用通常从服务器获取可执行代码。如果代码具有恶意行为，它可能在加密之前或解密之后访问内容。不能脱离代码的交付和执行方式来评估端到端加密。
对于安装版，软件包的真实性、更新和操作系统的安全状态同样重要。软件包签名和哈希检查有用，但不是对应用安全性的完整测试。Livara 威胁模型也指出，如果攻击者同时修改文件和显示的哈希值，仅仅哈希匹配并不能证明真实性。
Livara 提出了哪些声明？
根据 Livara 安全文档，私信使用 LVR1，兼容的私密群组使用 LGS1。文档描述了 P-256 与 ML-KEM-768 的组合以及消息内容加密。这些说明是产品声明，而不是本文进行独立审计所得的结论。
同一页面还说明会保留路由元数据，发布频道则是公开的。因此，正确结论不是“所有信息都被隐藏”或“不需要任何网络信任”，而是应将私密内容保护与连接、密钥交付、应用代码和元数据分开考察。
遇到证书警告该怎么办？
- 不要为了继续敏感聊天而忽略浏览器或应用的警告。
- 检查设备日期和服务的准确地址；并非每个证书错误都一定是攻击。
- 如果是组织管理的设备，请向获授权的管理员询问管理策略和已安装的证书；不要擅自更改受管理的设置。
- 不要仅因陌生消息的要求就安装证书或配置描述文件。
- 在敏感对话中，通过独立渠道与联系人核对密钥指纹；核对密钥不能代替解决 TLS 警告。
常见问题
VPN 能解决所有这些问题吗？
不能。VPN 可以改变流量被观察的路径，但不会自动修复受感染的设备、受信任的恶意证书或遭篡改的网页代码。
不发送密码的身份验证是否足够？
不够。身份验证协议、会话管理和消息加密的功能各不相同。虚假登录页面或恶意代码可以在协议执行前直接获取用户输入。
实用原则： E2EE 是有价值的一层保护，不要把它当作忽略证书、应用真实性或密钥验证的许可。
