HTML5推送加密方法全解析

HTML5推送消息的安全性完全依赖于RFC 8291标准规定的端到端加密机制——服务端必须使用客户端提供的P-256公钥（p256dh）和auth密钥，结合VAPID私钥执行ECDH密钥协商，并用派生密钥通过AES-GCM加密载荷，生成含salt、加密体和认证标签的二进制流；浏览器（Chrome/Firefox/Edge等）严格拒绝任何非标准格式（如明文、自定义加密或跳过VAPID签名），且客户端私钥永不离开设备，真正实现“服务端加密、客户端解密”的零信任模型——想让推送既抵达又保密？你必须放弃前端加密幻想，老老实实遵循Web Push协议的每一条加密铁律。

HTML5 本身不提供原生的推送消息加密能力，推送载荷（payload）的加密必须在应用层实现，核心在于：服务端加密 + 客户端解密，且依赖 Web Push 协议标准（RFC 8291） 规定的加密机制。浏览器（Chrome、Firefox、Edge 等）仅支持经过 Elliptic Curve Diffie-Hellman（ECDH）密钥协商 + AES-GCM 加密 的载荷，不接受明文或自定义加密格式。

必须使用 Web Push 标准加密流程

浏览器只接收符合 RFC 8291 的加密推送消息，否则直接丢弃。这意味着：

• 不能在 service worker 中用 CryptoJS 或 Web Crypto API 自行加密后发“明文”推送；
• 不能跳过 VAPID（Voluntary Application Server Identification）签名和密钥协商步骤；
• 客户端（service worker）生成的 publicKey/privateKey 对（P-256 曲线） 必须安全导出公钥并上传至服务端；
• 服务端需用该公钥 + 自己的 VAPID 私钥执行 ECDH 密钥派生，再用派生密钥 AES-GCM 加密载荷与 salt/nonce。

关键加密组件与职责分工

加密不是单点操作，而是端到端协作：

• 客户端（网页 + Service Worker）：生成 P-256 密钥对，通过 navigator.serviceWorker.register() 后调用 pushManager.subscribe() 获取 endpoint 和 keys.p256dh（公钥）、keys.auth（auth secret）；私钥永不离开设备；
• 服务端（Node.js / Python / Java 等）：使用 p256dh 和 auth，结合 VAPID 私钥，按 RFC 8291 执行加密（推荐使用成熟库如 web-push（Node.js）、pywebpush（Python））；
• 推送服务（如 Firebase Cloud Messaging、Mozilla Autopush）：仅中转已加密的 payload，不参与加解密，也不读取内容。

典型加密载荷结构（RFC 8291）

最终发送给推送服务的 HTTP POST body 是二进制（非 JSON），包含：

• salt（16 字节随机数）——用于 HKDF 派生密钥；
• record size header（可选，通常为 0x00）；
• AES-GCM 加密后的 payload（含认证标签，16 字节）；
• 所有内容以二进制字节流方式组织，Content-Encoding: aes128gcm，Encryption 和 Crypto-Key 头携带 p256dh 与 auth。

示例请求头：

常见误区与规避建议

• 误以为前端 JS 可“先加密再推送”：Service Worker 无法主动触发推送，推送由服务端发起；JS 无权限访问推送密钥私钥，也无法构造合规加密体；
• 忽略 VAPID 签名导致 401 错误：即使载荷加密正确，缺少合法 VAPID Authorization 头，推送服务会拒绝；
• 混淆 applicationServerKey 用途：它只是客户端密钥协商的“标识”，不是加密密钥；真正用于 ECDH 的是订阅时返回的 p256dh；
• 尝试加密空载荷或超长载荷：Chrome 限制加密载荷 ≤ 4096 字节（含开销），超限将被截断或失败；敏感数据建议仅传 ID，详情由客户端拉取。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~