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。
关键加密组件与职责分工
加密不是单点操作，而是端到端协作：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
-
客户端（网页 + 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。
示例请求头：
Content-Encoding: aes128gcmEncryption: salt=base64salt
Crypto-Key: keyid=p256dh; dh=base64p256dh, keyid=auth; key=base64auth
常见误区与规避建议
- 误以为前端 JS 可“先加密再推送”：Service Worker 无法主动触发推送，推送由服务端发起；JS 无权限访问推送密钥私钥，也无法构造合规加密体；
- 忽略 VAPID 签名导致 401 错误：即使载荷加密正确，缺少合法 VAPID Authorization 头，推送服务会拒绝；
-
混淆 applicationServerKey 用途：它只是客户端密钥协商的“标识”，不是加密密钥；真正用于 ECDH 的是订阅时返回的
p256dh； - 尝试加密空载荷或超长载荷：Chrome 限制加密载荷 ≤ 4096 字节（含开销），超限将被截断或失败；敏感数据建议仅传 ID，详情由客户端拉取。
