7. 安全考量
7. 安全考量
[RFC8030] 中的隐私与安全考量均适用于本机制的使用.
[RFC8188] 的安全考量一节说明了内容编码的局限. 尤其, 任何 HTTP 首部字段都不受内容编码方案保护. 用户代理 MUST 将 HTTP 首部字段视为来自推送服务.
尽管正确处理 HTTP 响应可能需要首部字段, 协议正确运行并不依赖它们. 若用户代理上的应用根据首部信息改变对推送消息的处理方式, 则会面临来自推送服务的攻击风险.
通信的时序与长度无法对推送服务隐藏. 外部观察者或许只能看到多条消息交织, 但推送服务能看到哪个应用服务器在与哪个用户代理通信以及所用订阅. 此外, 除非使用内容编码方案提供的填充来掩盖长度, 否则消息长度可能被泄露.
用户代理与应用 MUST 验证所收到的公钥位于 P-256 曲线上. 未校验公钥可能使攻击者提取私钥. 适当的校验步骤见 [X9.62] 第 4.3.7 节, 或 [KEYAGREEMENT] 第 5.6.2.3 节. 该过程包含三步:
-
验证 Y 不是无穷远点 (O),
-
对 Y = (x, y), 验证两个整数均在正确区间内,
-
确认 (x, y) 满足椭圆曲线方程.
对这些曲线, 实现者无需验证是否属于正确子群.
若将来需要替换本加密方案, 可定义新的内容编码方案. 为渐进部署新方案, 用户代理可公布其支持的内容编码. Push API [API] 中的 "supportedContentEncodings" 参数即为一例.