HTML5如何加密推送消息的载荷_HTML5推送载荷加密方案【归纳】

html5推送消息加密必须遵循rfc 8291标准，由服务端使用ecdh密钥协商与aes-gcm加密载荷，客户端仅生成并安全保管p-256密钥对，浏览器拒绝非标准加密格式。

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。

关键加密组件与职责分工

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

Decktopus AI

AI在线生成高质量演示文稿

下载

• 客户端（网页 + 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，详情由客户端拉取。